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Abstract 


Many  software  engineering  problems  stem,  in  part,  from  the  need  for 
software  designers  to  understand  specialized  knowledge  domains.  Current 
computer  software  systems  are  not  capable  of  representing  familiar 
calculation  features  such  as  equations,  tables,  graphs,  procedures,  and 
pictures  so  that  these  features  assist  humans  to  perform  calculations  in  a 
natural,  intuitive  way.  This  report  explains  the  need  for  these  features  to 
present  users  with  "natural"  ways  of  doing  calculations — that  is,  ways 
analogous  to  the  paper-based  techniques  used  in  the  absence  of  computers. 
Features  presented  in  this  way  would  make  computing  more  transparent  and 
intuitive.  In  the  Natural  Computing  approach  proposed  in  this  report,  software 
tools  are  first  developed  and  then  given  to  domain  specialists  to  use  in  their 
calculation  methods,  knowledge,  and  data.  As  domain  knowledge  changes 
and  grows,  and/or  new  calculation  methods  are  needed,  software  developers 
can  add  new  methods  and  procedures  to  the  existing  methods  (or  delete  old 
ones)  and  develop  successively  er\hanced  versions  of  application  software  for 
use  by  both  specialists  and  naive  end  users.  Domain  information  and 
knowledge  can  be  captured  in  electronic  books  and  commimicated 
electronically  for  further  expeditious  use.  Natural  Computing  eases 
application  system  development  and  accelerates  domain  knowledge 
dissemination,  leading  to  quicker  development  of  further  knowledge. 


11 


Contents 


1.  Introduction  . 1 

2.  Natural  Computing  Features  . 2 

3.  A  Textbook  Example  of  Natural  Computing  Features  . 3 

4.  Problems  With  Traditional  Software  Development  . 7 

4.1  Development  of  Tools  Versus  Development  of  Domain  Knowledge . 7 

4.2  Generic  Software . 8 

4.3  Ends  and  Means . 9 

5.  Information  Representations  and  Domains  . 11 

6.  Ideal  Characteristics  of  Software  Tools  . 18 

7.  Evolution  of  Computing  . 19 

8.  State  of  the  Art  of  Tables  in  Software  . 20 

8.1  Tables  in  Database  Systems . 20 

8.2  Tables  in  Text-Processing  Tools . 21 

8.3  Table  Usage  in  Real  World . 22 

9.  An  Analysis  of  Tables  . 23 

9.1  Anatomy  and  Morphology . 23 

9.1.1  Table  Parts . 23 

9.1.2  Capturing  Meanings  Expressed  in  Tables . 27 

9.2  Operations . 28 

9.3  Representation  of  Structure . 30 

9.4  Development,  Choice,  and  Use . 31 

9.5  Search  for  Data . 32 

9.6  Visibility  of  Data . 33 

9.7  Table  Data  Storage . 33 

9.8  Display . 33 

9.9  Testing  a  Table  in  Isolation . 33 

9.10  Growth  of  a  System . 34 

10.  Graphs  . 35 

10.1  State  of  Art  in  Graph  Representation . 35 

10.2  Natural  Computing  Graph  Representation . 36 

11.  Equations  . 39 

12.  Procedures  . 40 

13.  Pictures  . 41 

14.  Text  . 42 

15.  Conclusions  . 43 

Acknowledgments  . 44 

References  . 45 

Distribution  . 47 

Report  Documentation  Page  . 49 

iii 


Figures 


1.  A  sample  page  containing  text,  sketch,  and  equations . 4 

2.  A  sample  page  containing  text,  graph,  and  equations . 5 

3.  A  sample  page  containing  text,  table,  and  equations . 6 

4.  A  three-dimensional  plot  by  Mathematica® . 9 

5.  Ideal  gas  equation  with  notation . 11 

6.  Graphic  representation  of  temperature-volume-pressure  relationship  for  an  ideal 

gas . 12 

7.  A  C-I-+  program  for  ideal  gas  equation . 13 

8.  A  map  of  a  city  provides  navigational  information  to  a  traveler . 13 

9.  Algorithmic  description  of  a  route . 13 

10.  Status  of  American  and  National  leagues . 15 

11.  Simple  steam  power  plant  schematic  and  temperature-entropy  diagram . 15 

12.  Properties  of  steam  represented  on  a  Mollier  chart . 17 

13.  Chronological  sequence  in  ideal  Natural  Computing . 18 

14.  Chronological  sequence  in  current  standards . 18 

15.  Parts  of  a  table . 24 

16.  Anatomy  of  a  simple  table . 25 

17.  Table  column  header  object . 25 

18.  Table  data  body  object . 26 

19.  A  table  example  wherein  cells  in  a  column  contain  ranges  of  numbers . 28 

20.  A  spectrum  of  generable  table  types  in  profile  representation . 29 

21.  Cell-cage  array  connects  cell  locations  and  contents . 31 

22.  Adjacency  property  is  used  to  get  table  values . 32 

23.  Example  graph  showing  how  a  graphical  relationship  provides  visibility  to  data  and 

information . 36 

24.  An  example  showing  interactive  use  of  an  equation . 39 

25.  A  Natural  Computing  procedure  example . 40 

26.  Dimensions  from  a  sketch  used  in  an  equation . 41 

27.  Natural  computing  text  with  procedure . 42 

Tables 

1.  Tabular  representation  of  temperature-volume-pressure  relationship  for  an  ideal 

gas . 11 

2.  Performance  status  of  Yankees  on  a  particular  day . 14 

3.  A  table  in  a  word  processor  showing  an  element  spanning  two  columns . 22 

4.  Sales  in  East  Region . 29 

5.  Sales  in  West  Region . 29 

6.  Result  table:  sales  in  both  regions . 29 


IV 


1.  Introduction 


High  life-cycle  costs  and  poor  quality  are  the  main  problems  with  current 
software  development.  Several  methods  and  practices  have  been  pro¬ 
posed  to  address  these  problems,  with  limited  success.  One  of  the  more 
successful  approaches  is  to  develop  generic  tools,  such  as  those  for  word 
processing,  drawing,  and  databases;  these  have  resulted  in  the  economi¬ 
cal  development  of  software.  These  tools  have  become  very  affordable 
and  are  of  good  quality.  In  many  technical  scientific  domains,  however,  in 
which  computers  are  used  to  compute  in  the  earliest  sense  of  the  word — to 
make  calculations — software  development  is  still  complex,  slow,  unreli¬ 
able,  incomplete,  and  very  expensive.  The  result  is  that  software  for  literal 
computing  is  often  the  least  satisfactory  type  of  computer  software.  In 
large  part,  this  anomaly  arises  because  software  developers  and  domain 
specialists  are  usually  different  groups. 

The  approach  I  propose  in  this  report,  called  Natural  Computing,  is  in¬ 
tended  to  avoid  this  problem  by  providing  domain  specialists  with 
software  tools  whose  use  and  function  are  transparent  and  intuitive.  In 
the  term  Natural  Computing,  the  word  computing  is  thus  used  in  its  basic 
sense,  rather  than  the  extended  one  that  has  arisen  with  the  development 
of  modern  digital  computers  and  particularly  personal  computers.  The 
word  natural  is  used  to  refer  to  the  kind  of  understanding  of  paper-based 
means  of  computing  that  practitioners  of  technical  subjects  call  on  to  read 
and  work  with  technical  documents.  It  could  be  argued  that  these  tech¬ 
niques  are  hardly  natural,  since  they  have  been  developed  over  centuries 
(and  individual  people  must  learn  them  as  part  of  their  education  and 
technical  apprenticeship);  however,  I  argue  that  they  are  natural  in  the 
same  sense  that  many  learned  behaviors  (such  as  riding  a  bicycle)  can 
seem  natural  to  a  human  being.  It  is  natural  in  the  same  sense  that  com¬ 
puter  scientists  use  in  referring  to  the  specialized  field  of  natural  language. 
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2.  Natural  Computing  Features 

Since  Natural  Computing  is  based  on  the  way  people  actually  compute 
using  paper-based  techniques,  the  first  question  to  be  addressed  is  "How 
do  people  compute — using  available  information  of  all  types?"  Before  the 
invention  of  computers,  most  knowledge  was  captured  in  the  form  of 
books  and  other  paper  documents.  Books  can  be  further  classified  as 
textbooks,  reference  books,  handbooks,  and  journals,  based  on  the  tempo¬ 
ral  nature  of  the  information.  Other  documents  are  flyers,  brochures,  and 
receipts,  which  have  a  highly  transient  nature.  (I  use  books  and  documents 
interchangeably  to  refer  to  paper-based  information.)  Information  was 
printed  on  paper  for  storage,  retrieval,  and  commimication.  The  paper- 
based  information  was  read  by  the  end  user.  By  reading  the  information 
from  one  or  more  documents  and  by  combining  it  with  one's  own  intu¬ 
ition,  invention,  and  discovery,  one  generated  new  information  and  wrote 
(printed)  it  in  the  form  of  another  paper  document. 

When  we  dealt  with  technical  matter,  domain  knowledge  was  captured  in 
the  form  of  text  that  contained  equations,  tables,  graphs,*  and  pictures.'*’ 
Without  pictures,  descriptions  of  scenes  were  elaborate  (a  lot  of  text).  The 
famous  saying  "a  picture  is  worth  a  thousand  words"  sums  it  up.  Again, 
in  technical  subjects,  the  pictures  could  be  sketches,  schematics,  drawings, 
paintings,  or  photographs.  Sketches  stood  for  descriptions  of  parts  and 
components,  such  as  shapes  and  sizes.  Schematics  and  other  diagrams 
showed  the  mutual  relationships  of  components  in  a  system  and  the  state 
of  the  system  and  its  temporal  nature. 

Tables  captured  relationships  among  sets  of  variables.  Graphs  also  repre¬ 
sented  relationships  among  variables  but  additionally  provided  a  highly 
visual  insight  into  the  mutual  dependency  of  the  variables. 

Domain  specialists  read  the  text  and  concurrently  used  tables,  graphs, 
and  charts.  They  used  a  note  pad  to  make  temporary  notes  and  calcula¬ 
tions.  Simple  calculations  were  done  mentally.  More  complicated  calcula¬ 
tions  required  aids,  such  as  log  tables  and  slide  rules.  Domain  specialists 
captured  new  ideas  and  information  in  the  form  of  more  equations, 
tables,  graphs,  and  pictures;  appended  them  to  text;  and  commtmicated 
the  new  documents  to  others  in  the  field.  Documents  were  subject  to  three 
principal  types  of  use:  (1)  reading  and  comprehension;  (2)  interactive 
calculations  using  the  tables,  equations,  graphs,  and  pictures  along  with 
the  text;  and  (3)  development  and  recording  of  new  functions  (tables, 
equations,  graphs,  and  pictures).  Capturing  these  essential  natural  forms 
and  processes  in  a  computer  software  system  is  the  goal  of  Natural 
Computing. 


*The  term  graph  is  used  in  literature  with  various  meanings.  In  this  paper,  a  graph  means  a  curve  or  a  set 
of  curves  on  a  graph  paper.  Graphs  as  in  graph  theory  and  graphics  as  in  pictures  are  not  the  meanings 
implied. 

^The  term  picture  is  used  in  this  paper  to  include  sketches,  schematic  diagrams,  and  drawings.  It  does  not 
include  photographs  and  painted  pictures. 
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3.  A  Textbook  Example  of  Natural  Computing  Features 

An  example  of  paper-based  computation  tools  from  a  textbook  illustrates 
the  features  proposed  for  Natural  Computing.  Figure  1  shows  a  sample 
page  from  an  engineering  textbook  describing  mechanical  springs.  The 
page  consists  of  a  sketch  of  a  mechanical  spring,  text,  and  equations. 
Figure  2  shows  another  sample  page,  with  a  graph,  more  equations,  and 
more  text.  By  reading  the  explanations  on  these  pages,  an  engineer  will 
understand  the  domain  of  mechanical  springs.  An  engineer  can  study  the 
graph  on  the  page  and  understand  the  trends.  At  any  time,  the  engineer 
can  obtain  values  given  by  the  graphs — this  is  usually  called  reading  a 
graph.  While  using  these  pages,  the  engineer  starts  with  values  of  D  and 
d,  proceeds  to  calculate  the  value  of  the  variable  C  from  equation  8-1  (a 
reference  number  in  the  sample  page  (fig.  1)),  and  reads  the  value  of  the 
Wahl  correction  factor  K  from  the  graph  of  spring  index  versus  stress 
correction  factor.  This  value  of  K  and  an  input  value  of  F  (force)  are  next 
substituted  into  equation  8-4  and  the  value  of  stress  ris  calculated  (fig.  2). 
The  engineer  may  next  proceed  to  the  sample  page  shown  in  figure  3,  and 
read  the  values  of  A  and  m  for  a  given  material.  The  engineer  can  substi¬ 
tute  these  values  into  equation  8-10  to  calculate  the  ultimate  strength  in 
tension  of  the  spring  material. 

This  description  shows  that  domain  specialists  present  information  in 
textbooks  for  use  by  others  in  performing  calculations.  Thus,  textbooks 
are  used  both  to  explain  the  subject  and  to  provide  information  in  the 
form  of  text,  sketches,  equations,  graphs,  and  tables  for  ready  use  in 
calculations.  In  the  following  sections,  I  describe  how  traditional  comput¬ 
ing  (using  computer  software)  failed  to  follow  the  natural  calculations 
paradigm  and  is  accordingly  beset  by  problems. 
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FIGURE  8-1 

{a)  Axially  loaded  helical  spring;  (b)  free-body  diagram  showing  that  the  wire  is 
subjected  to  a  direct  shear  and  a  torsional  shear. 


the  hose  in  a  straight  line  perpendicular  to  the  plane  of  the  coil.  As  each  turn  of 
hose  is  pulled  off  the  coil,  the  hose  twists  or  turns  about  its  own  axis.  The  flexing 
of  a  helical  spring  creates  a  torsion  in  the  wire  in  a  similar  manner. 

Using  superposition,  the  maximum  stress  in  the  wire  may  be  computed 
using  the  equation 

Tr  F 


where  the  term  Tr/J  is  the  torsion  formula  of  Chap.  2.  Replacing  the  terms  by 
T  =  FD/l,  r  =  d/2,  J  -  ndF’/yi,  and  A  =  nd^/A  gives 


8f Z?  4F 

^  Tid^  nd^ 


(f>) 


In  this  equation  the  subscript  indicating  maximum  shear  stress  has  been  omitted 
as  unnecessary.  The  positive  signs  of  Eq.  (a)  have  been  retained,  and  hence  Eq.  (b) 
gives  the  shear  stress  at  the  inside  fiber  of  the  spring. 

Now  define  spring  index 


as  a  measure  of  coil  curvature.  With  this  relation,  Eq.  (b)  can  be  arranged  to  give 


Or  designating  =  1  -f  —  (8-2) 


Source:  Joseph  E.  Shigley  (1977).  Mechanical  Engineering  Design,  3rd  ed.,  McGraw-Hill  Book  Co., 
New  York,  NY. 


Figure  1.  A  sample  page  containing  text,  sketch,  and  equations. 
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FIGURE  8-2 

Values  of  the  stress  correction  factors  for  round  helical  extension  or  compression 
springs. 


then  ^  ~ 

where  is  called  a  shear-stress  multiplication  factor.  This  factor  can  be  obtained 
from  Fig.  8-2  for  the  usual  values  of  C.  For  most  springs,  C  will  range  from  about 
6  to  12.  Equation  (8-3)  is  quite  general  and  applies  for  both  static  and  dynamic 
loads.  It  gives  the  maximum  shear  stress  in  the  wire,  and  this  stress  occurs  at  the 
inner  fiber  of  the  spring. 

Many  writers  present  the  stress  equation  as 


T  =  X 


SFD 

nd^ 


(8-4) 


where  K  is  called  the  Wahl  correction  factor.*  This  factor  includes  the  direct  shear, 
together  with  another  effect  due  to  curvature.  As  shown  in  Fig.  8-3,  curvature  of 
the  wire  increases  the  stress  on  the  inside  of  the  spring  but  decreases  it  only 
slightly  on  the  outside.  The  value  of  K  may  be  obtained  from  the  equation 


K  = 


4C  -  1 
4C-4''' 


0.615 

C 


(8-5) 


or  from  Fig.  8-2. 

By  defining  K  =  K^K,,  where  is  the  effect  of  curvature  alone,  we  have 

K  -  (8.«) 


Source:  Joseph  E.  Shigley  (1977).  Mechanical  Engineering  Design,  3rd  ed.,  McGraw-Hill  Book  Co., 
New  York,  NY. 


Figure  2.  A  sample  page  containing  text,  graph,  and  equations. 
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strengths  for  various  wire  sizes  and  materials.*  But  the  availability  of  the  scientific 
electronic  calculator  now  makes  such  a  tabulation  unnecessary.  The  reason  for 
this  is  that  a  log-log  plot  of  the  tensile  strengths  versus  wire  diameters  is  a  straight 
line.  The  equation  of  this  line  can  be  written  in  terms  of  the  ordinary  logarithms  of 
the  strengths  and  wire  diameters.  This  equation  can  then  be  solved  to  give 

(8-10) 

where  A  is  a  constant  related  to  a  strength  intercept,  and  m  is  the  slope  of  the  line 
on  the  log-log  plot.  Of  course  such  an  equation  is  only  valid  for  a  limited  range  of 
wire  sizes.  Table  8-2  gives  values  of  m  and  the  constant  A  for  both  English  and  SI 
units  for  the  materials  listed  in  Table  8-1. 

Although  the  torsional  yield  strength  is  needed  to  design  springs,  sur¬ 
prisingly,  very  little  information  on  this  property  is  available.  Using  an  approxi¬ 
mate  relationship  between  yield  strength  and  ultimate  strength  in  tension, 

S,  =  0.75S„,  (8-11) 

and  then  applying  the  distortion-energy  theory  gives 

S,,  =  0.577Sy  (8-12) 

and  provides  us  with  a  means  of  estimating  the  torsional  yield  strength  S^y .  But 
this  method  should  not  be  used  if  experimental  data  are  available;  if  used,  a 
generous  factor  of  safety  should  be  employed,  especially  for  extension  springs, 
because  of  the  uncertainty  involved. 

Variations  in  the  wire  diameter  and  in  the  coil  diameter  of  the  spring  have  an 
effect  on  the  stress  as  well  as  on  the  spring  scale.  Large  tolerances  will  result  in 

*  See,  for  example,  the  second  edition  of  this  book:  Joseph  E.  Shigley,  "Mechanical  Engineering 
Design,”  2d  ed.,  p.  362,  McGraw-Hill  Book  Company,  New  York.  1972. 


Table  8-2  CONSTANTS  FOR  USE  IN  EQ.  (8-10)  TO  ESTIMATE  THE  TENSILE 
STRENGTH  OF  SELECTED  SPRING  STEELS 


Material 

Size  raage, 
in 

Size  range, 
mm 

Exponem, 

m 

Constant,  A 

kpsi  MPa 

Music  wire” 

0.00-M).250 

0.10-6.5 

0.146 

1% 

2170 

Oil-tempered  wire* 

0.020-0.500 

0.50-12 

0.186 

149 

1880 

Hard-drawn  wire” 

0.028-0.500 

0.70-12 

0.192 

136 

1750 

Chrome  vanadium” 

0.032-0.437 

0.80-12 

0.167 

169 

.2000 

Chrome  silicon' 

0.063-0.375 

1.6-10 

0.112 

202 

2000 

*  Surface  is  smooth,  free  from  defects,  and  with  a  bright  lustrous  finish. 

*  Has  a  slight  heat-treating  scale  which  must  be  removed  before  plating. 

'  Surface  is  smooth  and  bright,  with  no  visible  marks. 

‘  Aircraft-quality  tempered  wire;  can  also  be  obtained  annealed. 

'  Tempered  to  Rockwell  C49  but  may  also  be  obtained  untempered. 

Source:  Joseph  E.  Shigley  (1977).  Mechanical  Engineering  Design,  3rd  ed.,  McGraw-Hill  Book  Co., 
New  York, 


Figure  3.  A  sample  page  containing  text,  table,  and  equations. 
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4.  Problems  With  Traditional  Software  Development 

While  discussing  the  problems  plaguing  the  software  industry,  Coad  and 
Yourdon  (1991)  state,  "systems  analysts  must  first  understand  the  prob¬ 
lem  domain  at  hand."  They  also  answer  the  questions  "What  is  so  diffi¬ 
cult  about  analysis?  And  what  is  the  challenge?"  by  identifying  four 
major  difficulties  faced  by  systems  analysts  on  all  types  of  projects: 
problem  domain  understanding,  person-to-person  communication, 
continual  change,  and  reuse: 

•  Understanding.  Scientists  devote  their  lifetimes  to  understanding  their 
specific  domains  and  to  enriching  them  by  discovering  new  knowledge. 
No  wonder  software  systems  analysts  find  it  impossible  to  "understand" 
the  domain. 

•  Communication.  In  any  domain,  different  practitioners  hold  differing 
viewpoints  and  preconceptions  that  make  communications  among  them 
difficult.  Needless  to  say,  communication  with  outsiders  (such  as  systems 
analysts)  seems  well-nigh  impossible. 

•  Change.  As  scientists  work  in  a  specific  area,  they  hit  upon  new  ideas 
constantly — that  is  their  goal.  Therefore,  it  is  a  given  that  a  domain  will 
continually  change.  (Modeling  a  domain  that  has  ceased  growing  is  easier 
for  the  systems  analyst,  of  course,  but  the  result  may  not  be  useful.) 

•  Reuse.  Modern  economies  depend  on  the  reuse  of  all  knowledge  and  tools 
so  that  the  many  may  enjoy  the  fruits  of  the  labor  (and  inventiveness)  of 
the  few.  Bricks  and  bolts  and  nuts  are  probably  the  best  examples  of 
engineering  designs  of  great  reuse. 

One  can  avoid  these  four  types  of  difficulties,  which  are  inherent  in 
conventional  software  development,  by  using  Natural  Computing.  As  I 
conceive  it  in  Natural  Computing — 

•  Software  developers  do  not  need  to  understand  a  whole  domain:  they 
need  only  provide  building  blocks  for  the  specialist  to  work  with. 

•  Communication  between  domain  specialists  and  software  developers  at 
the  domain  level  of  abstraction  is  unnecessary. 

•  The  domain  will  be  extended  by  the  scientist  (or  engineer  or  domain 
analyst),  not  the  software  developer. 

•  Software  engineers  are  provided  ways  to  program  building  blocks. 

4.1  Development  of  Tools  Versus  Development  of  Domain 
Knowledge 

To  assist  a  discipline,  software  developers  do  not  need  to  grasp  all  the 
knowledge  of  that  discipline,  but  they  must  understand  its  language  and 
medium.  Every  field  has  developed  notations,  techniques,  and  methods 
for  facilitating  communications  among  practitioners  within  and  between 
fields.  Scientists  and  their  followers  constantly  reuse  these  forms  of 
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knowledge  for  further  understanding  and  for  applications  that  benefit 
society.  Both  the  methods  of  mathematicians  and  the  tools  and  techniques 
of  engineers  provide  such  benefits. 

Certain  disciplines,  such  as  mathematics,  enable  other  disciplines  to 
deliver  goods  to  society.  All  sciences  depend  on  mathematics  to  some 
degree  to  solve  problems  that  can  be  formulated  in  mathematical  termi¬ 
nology.  Mathematicians  do  not,  however,  insist  on  "xmderstanding"  a 
science  domain.  Consider,  for  example,  the  application  of  quadratic 
equations.  A  scientist  does  not  explain  a  domain  problem  to  a  mathemati¬ 
cian  so  that  a  quadratic  equation  solution  can  be  applied.  Instead,  math¬ 
ematicians  have  suggested  and  supplied  a  number  of  methods  for  solving 
quadratic  equations  without  regard  to  their  particular  application.  In 
general,  mathematicians  have  provided  scientists  with  a  vast  array  of 
theories  and  methods  (such  as  complex  variables,  Laplace  transforms, 
Fourier  transforms,  and  Bessel  functions).  Following  the  example  of  the 
mathematicians,  software  developers  and  software  engineers  should 
abstain  from  demanding  a  full  understanding  of  the  domain  in  which 
they  are  developing  applications.  They  will  be  able  to  contribute  to 
human  progress  by  providing  free-standing  methods  for  use  by  scientists 
and  engineers.  Software  engineering  professionals  should  develop  the 
tools  and  enable  the  domain  specialists  to  incorporate  the  domain  knowl¬ 
edge  and  methods  with  the  help  of  such  tools.  In  this  way,  software  is  like 
mathematics,  and  its  usefulness  to  humanity  can  be  realized  only  through 
other  domains. 

As  scientists  discover  new  facts,  they  codify  their  knowledge  and  present 
it  in  papers,  articles,  books,  and  handbooks.  This  knowledge  is  in  the 
form  of  text,  equations,  tables,  graphs,  procedures,  and  pictures.  These  are 
the  essential  forms  of  the  language  of  science  and  technology  (as  well  as 
of  other  domains  in  which  calculations  play  a  part,  such  as  engineering, 
accounting,  economics,  business  management,  and  (even)  political  sci¬ 
ence).  Natural  Computing  focuses  on  these  forms,  so  that  software  engi¬ 
neers  can  develop  tools  that  deal  with  computer  representations  of  these 
forms. 

Generic  Software 

Some  examples  of  generic  software  development  can  be  cited.  Word 
processing,  music,  and  graphics  programs  are  available  that  are  indepen¬ 
dent  of  a  specific  domain.  Because  these  software  tools  employ  the  users' 
language  and  notation  and  emulate  their  famihar  tools,  they  can  be  used 
by  a  variety  of  practitioners.  To  the  credit  of  such  generic  software,  musi¬ 
cians  can  use  computers  to  create  music,  and  painters  can  use  computers 
to  paint.  Software  developers,  in  general,  are  likely  to  agree  that  it  is  best 
to  assist  artists,  musicians,  and  painters  by  giving  them  appropriate  tools, 
rather  than  trying  to  understand  these  richly  complex  domains.  Unfortu¬ 
nately,  however,  when  it  comes  to  scientific,  engineering,  and  analysis 
domains,  developers  attempt  to  understand  the  domain  and  develop 
applications  programming.  This  is  the  crux  of  the  problem  in  software. 


Brooks  (1987)  argued  persuasively  that  there  are  no  magic  solutions  to  the 
fundamentally  difficult  problems  associated  with  software  development. 
There  are  no  panaceas — no  miracle  cures  that  will  automatically  increase 
our  productivity  by  orders  of  magnitude  while  eliminating  all  the  soft¬ 
ware  bugs.  However,  by  focusing  on  the  development  of  generic  tools, 
software  developers  can  reduce  software  bugs,  and  software  develop¬ 
ment  can  be  moved  to  a  higher  plane. 

4.3  Ends  and  Means 

Coad  and  Yourdon  (1991)  caution  software  practitioners  that  if  the  appli¬ 
cation  of  a  software  engineering  method  produces  a  monument  of  paper, 
then  something  is  wrong — in  the  method,  in  the  application  of  the 
method,  or  perhaps  in  both.  They  lament,  "if  we  lose  sight  of  people  and 
begin  producing  charts,  diagrams,  and  piles  of  paper  as  ends  [italics 
added]  unto  themselves,  we  fail  to  effectively  communicate."  Currently, 
most  software  methods  generate  displays  in  the  form  of  plots  or  tables 
that  can  be  used  as  records  but  not  as  dynamic  relationships.  Contrast  this 
with  a  scientist's  intuitive  and  interactive  use  of  tables  in  books.  A  scien¬ 
tist  can  readily  use  a  table  on  paper  either  to  read  or  as  a  relation  in  his  or 
her  computing.  Since  computer  tools  are  not  now  available  that  treat 
tables  as  relationships,  their  reuse  by  other  software  is  limited  and  circui¬ 
tous — reuse  depends,  in  fact,  on  the  scientist's  intervention  based  on 
understanding — ^just  as  with  a  paper  table.  In  a  similar  manner,  some 
programs  can  generate  graphs  in  vivid  colors  and  multiple  dimensions 
and  animations  (see  fig.  4,  generated  by  Mathematica®  (Wolfram,  1991)). 

Figure  4.  A  three-  ln[4]:=: 

dimensional  plot  by  Plot3D[SinW  Sin[y],  {x,  0,  2Pi},  h’,  0,  2Pi}] 

Mathematica®. 
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But  alas!  Neither  this  graph  nor  any  of  the  graphs  on  a  computer  screen 
are  meant  to  be  used  by  another  program. 

I  argue  that  text,  equations,  tables,  graphs,  pictures,  and  other  forms  of 
output  (ends)  generated  by  current  programs  should  actually  be  means  for 
communication  among  people,  understanding  by  people,  and  further 
generation  of  knowledge  by  people.  The  greatest  unmet  need  in  software 
engineering  is  developing  methods  and  tools  that  will  capture  equations, 
tables,  graphs,  procedures,  and  pictures  as  reusable  software  objects. 
Moreover,  these  forms  should  be  part  and  parcel  of  text  (computer  docu¬ 
ments),  just  as  they  are  in  current  paper-based  texts.  This  idea  is  at  the 
heart  of  Natural  Computing. 


5.  Information  Representations  and  Domains 


Equations,  graphs,  and  tables  are  all  intended  to  capture  and  represent 
functional  relationships  among  a  set  of  variables  in  a  given  domain.  In  the 
following  paragraphs,  1  present  examples  from  widely  different  domains 
to  stress  the  point  that  these  three  forms  can  represent  relationships  in 
those  domains.  First,  using  a  scientific  example,  I  consider  the  relation¬ 
ship  among  the  temperature,  pressure,  and  volume  of  a  gas.  In  the  sim¬ 
plest  case,  this  relationship  among  the  state  variables  (temperature, 
pressure,  and  volume)  is  represented  by  an  ideal  gas  equation  (fig.  5).  The 
same  relationship  can  be  represented  by  a  table  (table  1)  or  by  a  graph 
(fig.  6).  Any  one  of  the  three  forms  can  be  used  as  a  means  to  obtain  one 
value  of  a  state  variable,  given  values  of  the  other  two. 

Figure  5.  Ideal  gas 
equation  with 
notation. 


Ideal  gas  equation: 

V  =  RxT/p 

Notation: 

V  =  Volume,  ft^ 

R  =  Gas  constant,  ft-lbf/lbm-deg  R 
=  53.35  for  air 
T  =  Temperature,  deg  R 
p  =  Pressure,  psia 


Table  1.  Tabular 
representation  of 
temperature-volume- 
pressure  relationship 
for  an  ideal  gas. 


Table  1 .  Specific  volume  of  air  (ft^). 


Pressure 

psia 

14.7 

20 

30 

50 

60 

Temperature 
deg  R 

529.7 

13.35010157 

9.812325 

6.54155 

4.906162 

3.92493 

540.0 

13.60969388 

10.00313 

6.66875 

5.001563 

4.00125 

550.0 

13.86172525 

10.18837 

6.792245 

5.094184 

4.075347 

560.0 

14.11375661 

10.37361 

6.915741 

5.186806 

4.149444 

570.0 

14.36578798 

10.55885 

7.039236 

5.279427 

4.223542 

580.0 

14.61781935 

10.7441 

7.162731 

5.372049 

4.297639 

590.0 

14.86985072 

10.92934 

7.286227 

5.46467 

4.371736 

600.0 

15.12188209 

11.11458 

7.409722 

5.557292 

4.445833 
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Figure  6.  Graphic 
representation  of 
temperature-volume- 
pressure  relationship 
for  an  ideal  gas. 


1’  (volume,  ft3) 


Let  us  explore  the  genesis  of  the  three  forms  for  representing  relation¬ 
ships.  In  general,  mathematical  analysis  of  a  problem  results  in  a  func¬ 
tional  relationship  in  the  form  of  an  equation  that  we  can  use  in  further 
calculations.  Experimentally  observed  data  are  set  up  in  a  tabular  form,  or 
the  results  are  plotted  in  the  form  of  a  graph.  These  three  forms  of  repre¬ 
sentation  have  strong  and  weak  points.  Books  on  data  analysis  describe 
such  issues  in  detail,  which  are  beyond  the  scope  of  the  present  discus¬ 
sion.  I  limit  myself  to  a  few  remarks.  Graphs  show  the  highest  visibility  of 
trends.  Tables  provide  some  sense  for  trends  but  readily  reveal  magni¬ 
tudes.  Equations  are  compact,  but  provide  little  or  no  sense  of  the  trend 
(except  in  simple  cases).  Barring  such  specific  virtues,  these  three  forms 
are  identical  in  capturing  relationships  between  variables.  In  comparison 
with  these  three  forms,  a  black  box  computer  program,  which  can  also 
embody  the  relationship  among  the  variables,  has  the  least  visibility 
when  it  comes  to  revealing  the  trend  of  a  function  or  algorithm 
(see  fig.  7). 

As  an  example  of  states  of  a  system  and  information  about  the  system, 
consider  a  road  map.  It  represents  the  states,  which  are  map  locations. 
Roads  or  paths  connect  the  locations.  Eor  an  automobile  to  move  from 
location  A  to  location  B,  it  needs  to  take  a  certain  path.  A  map  helps  in 
determining  which  alternative  path(s)  will  take  an  automobile  from  A  to 
B.  A  map  is  two-dimensional  and  describes  a  location  in  terms  of  its  x  and 
y  coordinates.  If  we  superimpose  a  map  of  railroads  on  our  (road)  map 
example,  the  user  has  more  alternative  paths  to  take  from  A  to  B.  We  can 
provide  descriptive  directions  to  a  traveler  on  how  to  go  from  A  to  B,  or 
we  can  give  the  traveler  a  map  and  let  him  or  her  choose  a  path.  Giving 
directions  is  algorithmic  and  brief.  On  the  other  hand,  by  supplying  a 
map,  we  have  provided  the  traveler  with  considerable  information  and 
insight.  Now,  the  traveler  can  choose  the  shortest  path,  find  a  scenic 
route,  or  replan  the  route  if  a  roadblock  occurs  during  travel.  A  map  is 
actually  a  complex  graph.  Figures  8  and  9  present  examples  of  a  map  and 
algorithmic  directions,  respectively. 
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main  () 


Figure  7.  A  C++ 
program  for  ide 
equatioir. 


Figure  8.  A  map  of  a 
city  provides 
navigational 
information  to  a 
traveler. 


S^;'2mentc 


Figure  9.  Algorithmic 
description  of  a  route, 


From;  Sacramento  Met  Airport 

Take:  5  South 

Exit  to  Rte  80  east 

Exit  to  Rte  80  Bus  South 

Exit  to  Exposition  Blvd 

To:  Cal  Exposition 


Relationships  connect  the  various  states  of  a  system,  and  they  play  a  key 
role  in  the  description  of  a  system  as  they  describe  the  behavior  of  a 
system.  Consider  the  game  of  baseball.  Table  2  shows  the  performance  of 
the  New  York  Yankees  on  a  particular  day.  Figure  10  shows  the  state  of 
the  American  League  and  the  National  League  on  that  day  {The  Washing¬ 
ton  Post,  1996).  As  each  ball  is  played,  the  state  of  the  game  between  two 
opposing  teams  changes.  A  batter,  a  pitcher,  and  other  players  have 
attributes,  and  they  change  with  each  pitch  thrown.  Numerous  states  are 
recorded  by  official  scorers  and  by  baseball  connoisseurs  and  aficionados. 
Table  2  and  the  tables  in  figure  10  are  one  set  of  abstractions  or  represen¬ 
tations  of  all  possible  and  generatable  states. 

Groups  of  players  belong  to  a  team,  and  the  states  of  the  teams  (league) 
are  represented  in  the  table  in  figure  10.  When  the  results  of  the  next  day's 
games  are  available,  this  table  can  be  recalculated  according  to  a  set  of 
relationships.  Take,  for  example,  the  following  generic  equation; 

new  status  =  old  status  +  new  result. 


For  each  team, 

W  =  W  +  1  if  the  next  game  was  won  by  this  team,  or 
W  =  W  if  the  next  game  was  lost  or  postponed; 

L  =  L  +  1  if  the  next  game  played  was  lost  by  this  team,  or 
L  =  L  if  the  next  game  played  was  won  or  postponed; 

Pet  =  W/(W  +  L);  and  so  on. 

This  example  illustrates  that  a  system  has  many  states  and  that  a  given 
abstraction  captures  and  shows  selected  states.  States  comprise  sets  of 
variables  and  are  connected  by  means  of  relationships. 


Table  2.  Performance 
status  of  Yankees  on  a 
particular  day. 


New  York 

AB 

R 

H 

BI 

BB 

SO 

Avg 

Boggs  3b 

4 

0 

1 

1 

0 

0 

0.331 

Girardi  c 

4 

0 

0 

0 

0 

0 

0.282 

O'NeiU  rf 

3 

0 

1 

0 

1 

0 

0.368 

TMartinez  lb 

4 

0 

0 

0 

0 

0 

0.246 

Sierra  dh 

3 

2 

3 

0 

1 

0 

0.281 

Ouncan  3b 

4 

0 

0 

0 

0 

0 

0.343 

Ge Williams  If 

3 

0 

0 

1 

0 

0 

0.333 

RRivera  cf 

2 

0 

1 

1 

1 

0 

0.5 

Be  Williams  ph 

1 

0 

0 

0 

0 

1 

0.278 

DJeter  ss 

3 

1 

1 

0 

0 

0 

0.275 

Totals 

31 

3 

7 

3 

3 

1 

— 
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Finally,  I  present  a  technical  example,  the  case  of  a  thermal  system.  The 
operation  of  a  steam  plant  is  shown  in  figure  11.  There  are  four 
components:  a  boiler,  a  turbine,  a  condenser,  and  a  pump.  The  states  of 
the  working  fluid  (steam)  are  represented  on  a  temperature-entropy  (T-s) 
diagram  (Van  Wylen  and  Sonntag,  1965).  At  a  given  state,  the  properties 
(attributes)  of  the  steam  of  interest  to  a  thermal  engineer  are  p,  T,  v,  s,  and 
h.  Specific  relationships  apply  to  the  components  that  affect  a  change  in 


Figure  10.  Status  of 
American  and 
National  leagues. 
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Source:  The  Washmgton  Post,  Monday,  17  May  1996,  p  C6. 


Figure  11.  Simple 
steam  power  plant 
schematic  and 
temperature-entropy 
diagram. 


Source:  Gordon  J.  Van  Wylen  and  Richard  E.  Sonntag  (1965).  Fundamentals  of 
Classical  Thermodynamics,  John  WUey  cind  Sons,  Inc.,  New  York,  NY. 
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the  state  of  the  steam.  Expressed  in  other  words,  specific  paths  connect 
the  states  (1-2, 2-3, 3-4,  and  4-1).  Historically,  the  calculation  of  the  states 
(i.e.,  the  values  of  the  properties)  was  done  by  the  use  of  steam  tables  and 
steam  charts,  called  Mollier  diagrams  (fig.  12)  (Keenan  et  al,  1969). 

Mollier  charts  are  highly  visual,  and  their  use  made  the  "physics"  of  the 
steam  plant  process  highly  intuitive.  However,  charts  are  not  accurate, 
since  they  are  limited  by  dieir  scale.  The  use  of  steam  tables  improved  the 
accuracy  of  the  calculations,  albeit  at  the  expense  of  some  degree  of 
visibility.  Since  the  advent  of  digital  computers,  equations  were  fitted  (or 
derived)  for  the  behavior  of  steam.  The  equations  are  extremely  complex, 
and  their  solution  by  computer  algorithms  is  a  "black  box"  process. 

In  every  domain,  information  is  essentially  captured  and  represented  in 
the  form  of  equations,  tables,  and  graphs.  As  discussed  previously,  tradi¬ 
tional  computer  programs  catered  only  for  algorithmic  information. 
However,  since  people  need  both  information  and  algorithms  to  under¬ 
stand  the  principles  involved  in  the  domain  and  to  perform  calculations, 
a  scheme  where  both  information  and  algorithms  can  simultaneously  be 
represented  and  presented  has  great  merit  and  utility. 


6.  Ideal  Characteristics  of  Software  Tools 


Figure  13. 
Chronological 
sequence  in  ideal 
Natural  Computing. 


Figure  14. 
Chronological 
sequence  in  current 
standards. 


Having  described  the  features  of  paper-based  computing  that  people 
have  evolved  over  time,  I  am  ready  to  state  some  goals  for  Natural  Com¬ 
puting.  The  main  goal  of  good  software  tools  should  be  to  provide  a  user 
with  facilities  to  read,  interactively  calculate  (as  on  a  scratch  pad),  and 
develop  and  record  new  procedures  and  information  in  any  calculation¬ 
intensive  domain.  Once  such  good  tools  are  successfully  developed, 
electronic  information  processing  can  be  cleanly  divided  into  three  dis¬ 
tinct  parts:  (1)  software  tool  development,  (2)  domain  setup  and  knowl¬ 
edge  incorporation,  and  (3)  end  use.  In  such  a  scenario,  software  develop¬ 
ers  create  generic  tools  that  know  how  to  operate  on  text,  equations, 
tables,  graphs,  and  pictures.  Domain  specialists  set  up  and  incorporate 
data,  information,  and  procedures,  using  the  generic  tools  provided  to 
them  by  software  developers.  Finally,  end  users  use  the  domain  informa¬ 
tion  and  procedures  provided  to  them.  There  will  be  a  clean  and  clear-cut 
division  between  the  software  tool  development  and  the  domain  incorpo¬ 
ration.  Figure  13  shows  this  ideal,  in  contrast  with  figure  14,  which  shows 
what  is  currently  standard.  In  time,  as  newer  versions  of  software  tools 
with  greater  capabilities  evolve,  digital  computing  will  approach  what  is 
natural  to  people. 
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7.  Evolution  of  Computing 

Having  proposed  an  ideal  set  of  characteristics  for  computing,  I  now 
present  a  quick  survey  of  the  state  of  the  art.  Approaches  to  computer- 
based  calculations  have  continuously  evolved.  During  the  fifties  and 
sixties,  computers  were  seen  as  productivity  machines.  The  nature  of 
software  tools  or  languages  was  such  that  domain  specialists  could  use 
software  tools  to  speed  up  their  calculations  and  also  to  apply  them  to 
more  complex  problems.  It  was  found  to  be  more  effective  to  train  scien¬ 
tists  and  engineers  in  FORTRAN  programming  than  to  train  software 
developers  in  science.  Similarly,  finance  and  accounting  specialists 
adopted  COBOL  programming.  Note  that  software  developers  did  not 
need  to  "understand"  the  domain,  because  the  domain  specialists  knew 
the  programming  languages.  By  the  seventies,  however,  as  larger  com¬ 
puter  systems  became  available,  these  approaches  by  themselves  were  not 
adequate.  Rather  than  providing  appropriately  more  natural  FORTRAN 
and  COBOL,  software  developers  became  domain  software  developers. 
The  common  term  for  them  is  "application  developers." 

Till  recently,  text,  graphs,  equations,  and  pictures  did  not  coexist  in 
computer  documents.  The  eighties  saw  the  development  of  desktop 
publishing  systems  that  helped  us  create  excellent  documents  that  in¬ 
cluded  all  these  various  forms.  Even  so,  these  objects  are  generated  as 
ends  and  not  as  means  for  further  continual  computing.  That  is,  they  are 
representations  of  information  (just  like  traditional  paper  documents),  but 
they  are  not  tools  for  digital  computing. 

In  the  eighties,  a  number  of  generic  tools  emerged  that  permitted  scien¬ 
tists  and  others  to  work  in  symbolic  mathematics:  Macsyma,  SMP,  Re¬ 
duce,  MathCAD,  TKISolver,  and  Mathematica®.  The  popularity  and 
widespread  use  of  such  tools  demonstrate  that  domain  specialists  want 
better  and  more  natural  tools  and  not  the  personal  services  of  "applica¬ 
tion"  developers. 

Graphics  programming  tools  have  shown  that  points,  lines,  surfaces,  and 
so  forth,  are  the  language  features  of  a  variety  of  graphics  domains, 
whether  for  building  plans,  plumbing,  machine  designs,  or  integrated 
circuits.  The  graphics  programming  area  has  taken  giant  steps  in  develop¬ 
ing  natural  software  tools  that  graphic  artists  can  use.  Such  examples 
should  similarly  guide  us  in  recognizing  the  basic  features  that  are  ge¬ 
neric  to  calculations,  especially  while  one  is  using  graphs  and  pictures. 

If  we  follow  this  trend  into  software  for  calculations,  operations  on  tables, 
equations,  and  graphs  can  be  generic  or  domain-independent.  The  first 
step  to  progress  in  this  area  is  to  represent  computing  features  (tables, 
graphs,  equations,  etc)  as  objects,  through  object-oriented  programming. 
The  next  step  is  to  use  those  features  in  a  variety  of  domains. 
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8.  State  of  the  Art  of  Tables  in  Software 

Since  I  am  arguing  for  an  appropriate  representation  for  tables,  graphs, 
equations,  and  other  objects,  I  first  examine  the  state  of  the  art  in  comput¬ 
ing  with  respect  to  these  objects,  beginning  with  tables.  Tables  are  now 
used  mainly  in  two  principal  areas:  database  systems  and  text  processing. 

8.1  Tables  in  Database  Systems 

Date  (1995,  p  79)  calls  a  table  a  relation,  and  then  (p  80)  states,  "a  relation 
and  a  table  are  not  really  the  same  thing,  although  in  practice  it  is  fre¬ 
quently  convenient  to  pretend  that  they  are."  The  vast  literature  on 
database  systems  might  lead  an  unwary  reader  to  conclude  that  the 
database  community  has  already  represented  tables  in  a 
computer-usable  format.  However,  database  relations  do  not  allow 
people  to  use  the  most  common  tables  that  they  know.  This  situation  is 
due  to  the  mathematical  rigor  of  the  database  systems.  Software  develop¬ 
ers  are  caught  in  a  dilemma  between  mathematical  rigor  and  the  natural 
but  highly  flexible  forms  people  use.  For  example,  study  the  baseball 
tables  in  figure  10  and  table  2.  Six-year-old  children  grasp  the  nuances  of 
these  tables.  These  simple-looking  tables  represent  many  relationships. 
Lay  readers  can  quickly  compare  and  calculate  desired  outcomes.  As  new 
baseball  games  are  played  each  day,  new  tables  of  values  can  be  calcu¬ 
lated  from  new  data,  old  table  values,  and  predefined  relationships 
(formulas).  Databases  are  not  meant  to  be  used  that  way. 

Shaler  et  al  (1988)  discuss  formalizing  the  concept  of  a  table,  including 
normalization  rules  for  producing  well-formed  tables.  According  to 
Shaler  et  al,  the  normalization  rules  can  be  viewed  from  two  perspectives. 
The  first  focuses  on  the  form  of  data  in  databases;  these  rules  tell  how  to 
set  up  tables  so  that  there  is  little  redundancy  in  the  data — that  is,  the 
amount  of  data  required  to  store  a  certain  information  content  is  mini¬ 
mized.  The  second  perspective  (the  one  most  natural  to  us)  looks  at  the 
normalization  rules  as  statements  about  the  repertoire  of  forms  that  we 
use  in  our  model  (the  fact  that  we  are  using  tables,  for  example),  and  the 
meaning  we  imply  whenever  we  use  a  form  in  a  particular  manner. 

Date  (1995)  describes  a  database  system  as  basically  a  computerized 
"record-keeping"  system.  Its  overall  purpose  is  to  maintain  information 
and  to  make  that  information  available  on  demand.  Date  considers  three 
classes  of  users:  the  application  programmers,  the  end  users,  and  the 
database  administrators.  Date  also  gives  a  slightly  more  precise  definition 
of  the  database:  "A  database  consists  of  some  collection  of  persistent  data 
that  is  used  by  application  systems  of  some  given  enterprise." 

While  defining  what  a  relational  system  is.  Date  states  that  in  the  rela¬ 
tional  system,  the  user  perceives  the  data  as  tables  (and  nothing  but 
tables)  (p  22).  He  goes  on  to  state,  "For  most  practical  purposes,  indeed, 
the  terms  relation  and  table  can  be  taken  to  be  synonymous."  The  rela¬ 
tional  model  is  a  way  of  looking  at  data — that  is,  it  is  a  prescription  for  a 
way  of  representing  data  (namely,  by  means  of  tables). 
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A  scrutiny  of  table  2  and  the  tables  in  figure  10  will  reveal  the  simple¬ 
appearing  means  used  by  natural  tables  to  represent  a  variety  of  complex 
relationships;  by  contrast,  the  best  database  systems  are  much  more 
limited.  For  example,  in  natural  tables,  ranges  are  represented,  blanks  are 
allowed  with  definite  meanings,  and  data  types  are  mixed  with  no  prob¬ 
lems.  In  the  first  column  of  table  2,  notice  how  a  batter  and  information 
on  his  field  position  are  combined!  A  database  system  will  not  allow  such 
mixing. 

Despite  the  extensive  use  and  discussion  of  "tables"  in  database  systems, 
these  entities  are  much  more  limited  than  real-world  tables  and  do  not 
provide  a  way  to  capture  the  complex  relationships  that  natural  tables 
embody. 

8.2  Tables  in  Text-Processing  Tools 

As  suggested  earlier,  tables  in  word  processors  and  publishing  tools  are 
displays  only;  the  meaning  relationships  among  the  elements  are  sup¬ 
plied  by  the  reader  and  are  not  inherent  in  the  tables  themselves.  Discus¬ 
sions  of  tables  in  text  processing  accordingly  focus  on  their  display 
features. 

Morris  (1996,  p  79)  describes  how  tables  are  formatted  and  added  as  a 
new  feature  of  Hypertext  Mark-Up  Language  (HTML)  so  that  HTML  can 
become  a  true  publishing  medium.  As  is  common  with  HTML  docu¬ 
ments,  tags  are  used  to  define  a  table  and  its  components.  A  table  is 
divided  into  rows  and  cells.  Techniques  are  defined  to  format  text  in  table 
cells.  However,  these  formatting  rules  are  merely  to  represent  tables  for 
display.  Creation  and  editing  are  permitted,  but  no  other  data  manipula¬ 
tion  and  use  are  possible  at  present. 

Lemay  (1996,  pp  194, 440)  discusses  formatting  of  tables  for  use  on  the 
World  Wide  Web,  and  again  the  emphasis  is  on  creating  tables  at  the 
transmitter's  terminal  (or  server)  and  their  display  at  the  receivers' 

(client)  terminals.  To  add  tables  to  your  web  page,  Netscape  features  table 
heading  cells  and  table  data  cells.  Lemay  also  suggests  the  use  of  lists, 
images,  and  preformatted  text  as  alternatives  to  tables. 

In  its  "Autoformat"  feature,  Microsoft  Word  (version  7.0, 1995)  accommo¬ 
dates  38  different  formats  for  a  table.  It  also  allows  for  columns  to  be  split 
(table  3).  However,  the  purpose  of  these  operations  is  display  in  a  natural¬ 
looking  fashion.  But  no  methods  exist  that  support  the  placement,  re¬ 
trieval,  or  manipulation  of  data. 

As  this  brief  discussion  shows,  although  modern  text-processing  tools 
provide  more  or  less  sophisticated  methods  for  creating  tables  as  dis¬ 
plays,  they  provide  no  tools  for  capturing  the  relationships  represented 
by  tables.  Just  like  paper  tables,  these  (text  processing)  tables  rely  on  a 
human  interpreter  to  supply  meaning. 
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Table  3.  A  table  in  a 
word  processor 
showing  an  element 
spanning  two 
columns. 


8.3 


Monday  Tuesday  Wednesday  Thursday 

AM  PM 


Table  Usage  in  Real  World 

In  the  examples  of  tables  given  in  section  5, 1  chose  the  baseball  tables  to 
illustrate  the  ubiquity  of  tables  in  the  real  world.  A  four-  to  six-year-old 
(in  U.S.)  understands  a  baseball  table.  A  child  of  four  understands  a  table 
of  menus  and  prices  at  a  fast-food  restaurant.  With  only  a  basic  knowl¬ 
edge,  the  child  can  easily  process  this  table.  Humans  gain  such  processing 
knowledge  independent  of  the  domain.  It  appears  that,  initially,  they 
apply  the  processing  knowledge  to  simple  cases  in  their  favorite  domains 
and  later  extend  it  to  complex  domains.  As  people  grow,  they  compre¬ 
hend  more  complex  table  constructions.  With  a  little  help,  or  through 
exploration,  they  understand  tables  of  increasing  complexity.  And  they 
continually  add  more  complex  tables  to  their  repertoire.  That  is  the  nature 
of  our  learning! 

A  teenage  student  may  have  problems  with  school  homework  but  vmder- 
stands  tables  comparing  automobiles  in  the  April  issue  of  Consumer 
Reports.  These  tables  do  not  even  use  numbers  in  the  cells.  Circles  filled 
with  red  and  black  colors  are  used,  and  footnotes  explain  what  the  vari¬ 
ous  colored  circles  mean. 

On  a  more  advanced  level,  the  example  of  logarithmic  tables  demon¬ 
strates  that  a  table  can  be  much  more  than  the  record-keeping  tool  of 
database  programming.  Before  the  slide  rule,  the  calculator,  and  the 
computer  led  to  their  demise,  log  tables  were  used  by  scientists  and 
engineers  as  an  integral  part  of  a  calculation.  Each  table  element  entry  in 
the  body  of  a  log  table  is  the  value  of  the  logarithm  of  a  given  number 
indicated  by  a  combination  of  row  and  column  heading.  (This  convention 
alone  is  sufficient  to  show  that  a  table  is  not  merely  a  database.)  A 
complementary  table  contains  antilogarithms.  Other  examples  of  tables 
used  directly  to  facilitate  computations  are  tables  of  values  of  sine,  cosine, 
tangent,  sinh,  cosinh,  tanh,  and  so  forth. 

Of  course,  those  well  versed  in  mathematics  preferred  to  use  equations 
rather  than  resorting  to  tables,  and  still  others  represented  the  functional 
relationship  in  a  graphical  form — a  curve.  This  is  an  instance  of  the  same 
functional  relationship  among  variables  being  represented  by  tables, 
equations,  and  graphs.  In  other  instances,  such  as  experimental  data  and 
empirical  observations  (e.g.,  baseball  results),  where  equations  are  diffi¬ 
cult  to  fit,  tables  of  data  are  the  only  recourse. 

How  do  we  use  tables?  As  a  relation  is  the  simple  answer — or  as  a  reposi¬ 
tory.  We  use  tables  to  obtain  textual  information,  symbolic  information, 
graphic  information,  and  finally  numerical  data.  But  most  of  all,  we 
interpret  the  information  for  subsequent  and  continual  use.  Our  software 
versions  of  tables  should  allow  us  to  do  the  same  things. 
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9.  An  Analysis  of  Tables 

Having  described  in  the  previous  section  how  tables  are  represented  in 
traditional  databases  and  text-processing  documents,  I  analyze  in  this 
section  some  characteristics  of  tables  as  they  are  used  in  real  life,  describ¬ 
ing  their  anatomy  and  morphology;  I  suggest  that  these  characteristics 
should  be  captured  in  software,  so  as  to  allow  software  operations  on 
tables  that  parallel  the  real-world  operations  that  scientists  and  engineers 
perform  with  paper  tables. 

A  body  of  knowledge  has  developed  about  tables,  their  representation, 
and  their  behavior.  This  knowledge  is  essentially  empirical  and  unwrit¬ 
ten.  When  we  try  to  program  the  structure  and  behavior  of  tables  in 
software,  it  is  important  to  understand  and  capture  these  traditional 
conventions  and  nuances. 

9.1  Anatomy  and  Morphology 

9.1.1  Table  Parts 

Figure  15  shows  the  terminology  for  parts  of  a  table  used  in  printing  by 
the  U.S.  Government  Printing  Office  (GPO,  1984).  However,  since  such 
terminology  is  not  inclusive  (and  much  of  it  is  related  strictly  to  the 
display  aspect  of  tables),  I  depart  from  it  and  use  my  own  terms  for 
certain  parts  of  a  table. 

A  table  represents  some  characteristics  and  values  in  a  domain  (such  as 
the  standings  of  a  baseball  team).  Here  I  start  with  a  two-dimensional 
rectangular  array  as  a  common  example  of  a  table,  while  not  restricting 
my  discussion  to  it.  As  shown  in  figure  16,  a  table  can  be  divided  into  the 
title,  the  set  of  column  labels,  and  the  table  body;  further,  within  the  body, 
the  first  column  often  has  special  status. 

The  table  caption  gives  it  an  identity,  describing  the  subject  matter  of  the 
table.  In  documents  such  as  books,  we  find  lists  of  tables  that  bring 
together  all  the  table  titles  to  one  location.  The  list  of  titles  (including  page 
numbers)  is  called  the  table  of  contents  and  is  used  as  an  index  into  the 
book. 

I  refer  to  the  set  of  colurrm  labels  as  the  column  header,  which  is  called  in 
GPO  terms  the  "boxhead."  This  part  of  the  table  describes  the  characteris¬ 
tics  that  are  represented  in  the  columns.  Table  column  headers  (boxheads) 
are  usually  complex  data  forms.  For  example,  the  elements  may  carry  a 
characteristic,  an  abbreviated  variable  or  symbol  standing  for  the  charac¬ 
teristic,  and  appropriate  xmits  for  the  characteristic — such  as  "Frequency,/ 
(Hz)."  It  is  often  not  sufficient  to  represent  a  characteristic  alone;  for 
practical  utility,  its  units  must  also  be  included.  User-friendly,  practical 
tables  show  the  units  for  a  given  characteristic  in  the  same  or  in  an  adjoin¬ 
ing  element.  Figure  17  shows  the  anatomy  of  a  table  column  header 
(boxhead). 
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DEFINITION  AND  PARTS  OF  A  TABLE 

To  define  and  describe  fully  all  of  the  many  parts,  terms,  and  details  which  enter  into  tabular  presentation  is 
difficult  to  explain  in  a  few  woras  or  to  understand  readily  without  an  accompanying  visual  example.  The  example 
shown  is  directed  at  those  concerned  with  the  construction  and  makeup  of  tables,  with  guidelines  identifying 
tabular  terms  and  details.  Many  of  the  terms  can  be  applied  to  any  form  of  tabular  matter. 
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Stub  column  Figures  bear  off  Readirtg  column 


Cutoff  rule— 


Colon  line- 


Subentry 
Flush  line— 


Bunover  indention 


2  IKASINO  COLUMNS 

(Leader  from  top  line) 

1  Dairy  products: 

2  In  ctns  (pounds)  ■>...  1,485,692  380  462  .  3,624  Mar.  8, 19^ .  Reading  column. 

8  In  cane  (pounds) .  263.491  .  198  8.762  5.783  Dec.  17, 1957.....  Po. 

4  Clay  products  (other  325,000  621  .  4,111  1.926  Nov.  26. 195?....  Do. 

than  pottery,  refrac- 
tones)  (boxes). 

5  Ferrous  alloys  (tons)......  163,361  556  276  1.985112,812  ......do .  Same  reading 

column. 


1  aXADINO  COLUMN 


I 

*  1 

Reading  column .  2 

. do .  S 

. do...._ .  4 


Same  reading  column..  5 


(Leader  from  bottom  line) 


Foot  or  bottom  rule. 
usually  kairUne 
and  single 


2  A  long,  crowded  line 

(thousands  of  tons) .... 

3  A  very  long  line  that 

runs  over  (crates) . 


13,092 

748 

365  2,421 

986 

7,654,000 

5,137 

5,692 

345 

721  2,679 

3,542 

962.111 

4,728 

886,591 

476 

582  13,563 

12.297 

82,129 

18.591.763 

If  tracer- 
figure  (line 
number)  column 
is  used  on 
right,  preceding 
column  will 
carry  leaders 
to  adjacent 
cast  and 


Traoer- 

figure 

(line 

number) 

column 

r 


from  top 


Footnotes  or  reference- 
lines 


‘  Reference  number  in  boiheading. 

I  *  Reference  number  followed  by  leaden  in  itub  or  inside  reading  column. 

I  *  Reference  number  in  figure  column. 

I  *  Reference  number  in  last  or  outeide  reading  column. 

I  ^  Reference  number  following  ‘'do"  in  inside  roeding  column. 

I  *  Reference  number  following  “Do"  in  last  or  outaide  column. 

{*  R^erence  number  standing  alone  in  iaat  or  outaide  column,  encloaed  in  parentbaaea  followed  by  period  "I’).,"  and 
quadded  out  to  end  of  line. 

I  *  Reference  number  standing  alone  in  figure  oolumn.  encloeed  in  parentheaee  (*)- 

I  *  Reference  number  standing  alone  in  inaide  reading  column,  encloaed  in  pareniheaea  I*),  and  leadered  out  to 

I  cast  on  rii^t. 


Non.— If  no  tnear-figure  column  ia  uaad  on  the  laft  of  table  and  the  stub  or  reading  column  i 
fluah,  "Do."  will  be  capitalised  and  leadered  out  to  caat  on  right 


set 


Source:  U.S.  GPO  (1984).  LI.S.  Government  Printing  Ojfice  Style  Manual,  Washington,  D.C. 


Figure  15.  Parts  of  a  table. 
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TABULAR  WORK 


Figure  16.  Anatomy  of 
a  simple  table. 


Figure  17.  Table 
column  header 
(boxhead)  object. 


The  table  body  contains  the  data  characterized  in  the  column  header.  The 
elements  in  each  column  represent  values  pertaining  to  the  corresponding 
column  label.  The  elements  along  a  row  also  usually  form  a  consistent  set; 
that  is,  they  relate  properties  of  a  given  state.*  Consequently,  each  element 
in  a  table  body  is  associated  with  its  neighbors  in  a  row  and  with  its 
neighbors  in  a  column. 


*ln  some  unusual  tables,  the  columns  are  merely  rmassociated  lists.  Although  such  tables  are  the  minority, 
they  should  be  included  in  the  analysis.  One  way  to  analyze  such  a  column  might  be  as  one  cell  contain¬ 
ing  a  list,  rather  than  a  set  of  cells.  Natural  Computing  software  should  be  able  to  reveal  both  relation¬ 
ships  and  lack  of  relationship. 
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An  element  in  a  table  body  can  be  a  number,  text,  a  graphic  symbol,  or 
any  combination  that  makes  sense  to  a  user.  Elements  within  a  table  can 
represent  continuous  states  of  a  field  (such  as  the  thermal  properties  of  a 
gas  or  the  depth  of  a  sea  over  a  given  area).  Or  the  values  in  the  table  can 
be  discrete  and  represent  values  only  at  distinct  (finite)  states.  In  the 
former,  values  can  be  interpolated,  while  interpolation  is  meaningless  in 
the  latter. 

Table  data  body  elements  (fig.  18)  are  usually  uniform,  being  either 
textual  data  or  numbers.  But  it  is  not  uncommon  to  see  variations  and 
omissions  on  this  uniformity  of  data.  Table  elements  carry  blanks,  dashed 
lines,  a  series  of  dots,  remarks,  and  so  forth. 

The  first  column  in  many  tables  stands  in  a  special  relationship  to  the 
other  columns;  elements  in  the  first  column  often  characterize  in  some 
way  the  other  elements  in  the  rows.  (In  GPO  terminology,  the  first  col¬ 
umn  is  called  the  "stub"  column;  see  fig.  15.)  This  relationship  may  be 
similar  to  that  between  the  column  header  and  the  table  body;  for  some 
tables,  the  first  column  could  act  as  the  column  header  if  the  table  were 
rotated  90°.  I  refer  to  such  a  column  as  a  row  header,  to  capture  the  parallel 
with  the  column  header.  (Although  it  is  not  at  the  head  of  the  table  in  the 
sense  of  being  at  the  top  (as  the  column  header  is),  its  elements  act  as  the 
"heads"  of  each  row  in  a  "command"  sense.)  It  is  also  not  unusual  to  find 
labeled  subdivisions  in  a  row  header  (in  GPO  terms,  "centerheads"  in  the 
stub  column).  These  labels  correspond  to  spanner  heads  in  the  boxhead 
(see  fig.  15),  and  reveal  another  way  in  which  column  headers  and  row 
headers  can  have  parallel  functions.  In  some  types  of  tables,  the  first 
column  information  may  be  interpreted  as  the  independent  variable  on 
which  information  in  the  other  columns  depends;  for  some  relationships, 
it  may  be  possible  to  "promote"  another  column  to  the  first  position  and 
thus  treat  its  information  as  independent.  The  various  meanings  that  the 
first  column  can  carry  will  require  careful  analysis. 


Figure  18.  Table  data 
body  object. 
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A  common  optional  feature  of  tables  is  notes.  These  qualification  marks 
(head  notes  or  footnotes)  may  be  carried  by  some  table  elements.  Some 
apply  to  the  whole  table,  while  others  apply  to  specific  rows,  columns,  or 
elements.  Domain  specialists  use  these  marks  and  footnoted  explanations 
to  capture  the  vagaries  of  information.  Users  are  expected  to  be  cautious 
of  the  notes  and  be  sure  to  apply  necessary  checks  for  maximum  validity 
of  the  data  and  information. 

9.1.2  Capturing  Meanings  Expressed  in  Tables 

Real-world  tables  made  up  of  the  generic  parts  just  described  are  used  to 
express  a  variety  of  relationships.  Over  the  years,  people  have  developed 
table  conventions  that  allow  us  to  indicate  these  relationships,  their 
applicability,  and  their  limits.  In  Natural  Computing,  we  will  require 
software  tools  that  are  sufficiently  rich  to  capture  these  meanings. 

The  steam  tables  alluded  to  earlier  (sect.  5)  demonstrate  the  generic 
structure  and  behavior  of  a  table.  Steam  has  a  thermodynamic  state, 
which  is  captured  as  a  number  of  properties:  pressure,  temperature, 
specific  volume,  internal  energy,  enthalpy,  and  entropy.  Given  any  two  of 
these  properties,  the  state  is  completely  defined.  Hence,  the  properties  of 
steam  or  other  gases  can  be  represented  by  means  of  a  two-dimensional 
table.  No  matter  which  gas  the  table  represents,  the  structure  and  behav¬ 
ior  of  a  table  are  generic  from  a  software  development  perspective. 

In  some  tables,  the  functional  relationship  holds  only  at  the  points  given 
in  the  table,  whereas  in  others,  the  data  can  be  interpolated  and/or 
extrapolated.  Thus,  Natural  Computing  will  require  the  implementation 
of  tables  with  differing  behavior.  Whether  and  how  interpolation  is  done 
would  be  a  property  of  the  table:  interpolations  and  extrapolations  can  be 
along  the  rows,  colurrms,  or  both;  also,  this  property  would  define  which 
of  several  types  of  interpolations  apply  (arithmetic  interpolation  being  the 
most  common). 

An  interesting  example  is  presented  in  figure  19,  where  cells  in  a  column 
contain  ranges  of  numbers  (Shigley,  1977).  When  cells  are  filled  with 
ranges  instead  of  single  numbers,  we  can  (in  essence)  avoid  the  need  for 
many  if-then  or  switch-and-case  statements  in  programming  by  the 
appropriate  use  of  such  table  columns.  In  the  example  table,  the  first  row 
of  values  can  be  used  only  if  the  size  range  is  within  0.004  to  0.250  in.  This 
demonstrates  a  clever  means  of  representing  an  IF  statement  in  a  table!  In 
some  cases,  as  in  the  spring  materials  example  shown  in  the  figure,  a 
table  element  may  prescribe  an  allowable  range  for  the  rest  of  the  rela¬ 
tionship  to  hold.  Ordinarily,  however,  an  allowable  point  value  is 
prescribed. 

Table  cells  may  contain  the  results  of  manipulation  of  other  cells  (e.g.,  the 
sum  of  values  of  a  number  of  other  designated  cells),  as  in  a  spreadsheet. 
(Before  the  development  of  computer  spreadsheets,  people  used  such 
methods  with  simple  tables  and  called  them  "worksheets.")  In  some 
instances,  the  value  obtained  from  the  table  element  is  modified  based  on 
footnotes  or  other  notes.  Thus  a  table  is  not  merely  a  lookup  table;  it  also 
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Figure  19.  A  table 
example  wherein 
cells  in  a  colrunn 
contain  ranges  of 
numbers. 


informs  us  to  look  out  for  footnoted  interpretations  based  on  conditions.  I 
call  this  quality  the  responsibility  of  an  object  during  computations.  In  the 
Natural  Computing  approach  to  tables,  it  is  important  to  ensure  that  a 
table  object  behaves  responsibly;  that  is,  it  must  account  for  the  footnotes, 
the  exceptions,  and  the  units.  The  software  tool  developer,  who  develops 
table  classes,  should  endow  the  tables  with  the  correct  behavior  (for 
example,  interpolation  allowed  or  disallowed).  The  domain  specialist, 
who  programs  a  specific  calculation  and  information  in  the  domain, 
should  select  the  table  with  the  right  behavior.  If  the  table  object  behaves 
responsibly,  the  naive  end  user  will  have  no  problems  with  the  tables  and 
with  the  calculation  capabilities  of  those  tables. 

Another  aspect  of  a  responsible  table  in  my  sense  is  the  proper  treatment 
of  units.  In  the  real  world,  variables  do  not  come  with  consistent  units 
across  all  interfaces  and  applications.  For  example,  clothing  manufactur¬ 
ers  buy  cloth  in  yards,  but  pattern  cutters  use  inches  for  their  measure¬ 
ments.  We  may  enter  a  table  with  one  set  of  units,  while  the  table  values 
are  in  a  different  set  of  units.  The  responsible  user-friendly  table  should 
accommodate  any  consistent  set  of  units. 

Figure  20  shows  a  spectrum  of  tables  (classes  and  categories).  This  dis¬ 
play  is  called  a  profile  representation  of  options  (Warfield,  1994,  and 
Warfield  and  Cardenas,  1994).  It  shows  that  a  table  header  can  have  three 
options,  a  cell  cage  can  have  four  options,  and  so  on.  As  we  pick  each 
option  and  explore  the  various  combinations,  a  large  number  of  practical 
tables  can  be  covered  for  representation  in  the  Natural  Computing 
system. 

9.2  Operations 


TiM*  8-2  CONSTANTS  FOR  USE  IN  EQ.  (8-10)  TO  ESTIMATE  THE  TENSILE 
STRENGTH  OF  SELECTED  SPRING  STEELS 


Caanant,  A 


Material 

Sin  raw» 
in 

Sinnnge, 

mm 

Expoaem, 

m 

kpai 

MPa 

Music  wire* 

0.004-0.250 

0.10-6.5 

0.146 

196 

2170 

Oil-tempered  wire* 

0.020-0.500 

0.50-12 

0.186 

149 

1880 

Hard-drawn  wire' 

0.O28-0J0O 

0.70-12 

0.192 

136 

1750 

Chrome  vanadium^ 

0.032-0-437 

0.80-12 

0.167 

169 

2000 

Chrome  silicon' 

0.063-0.375 

1.6-10 

0.112 

202 

2000 

“  Surface  is  smooth,  free  from  defects,  and  with  a  bright  lustrous  finish. 

*  Has  a  slight  heat-treating  scale  which  must  be  removed  before  plating. 
'  Surface  is  smooth  and  bright,  with  no  visible  marks. 

'  Aircraft-quality  tempered  wire;  can  also  be  obtained  annealed. 

'  Tempered  to  Rockwell  C49  but  may  also  be  obtained  untempered. 


Source:  Joseph  E.  Shigley  (1977).  Mechanical  Engineering  Design,  3rd  ed., 
McGraw-Hill  Book  Co.,  New  York,  NY. 


The  extraction  of  information  from  a  table  is  one  of  the  simplest  of  opera¬ 
tions  possible  with  a  table.  People  perform  far  more  sophisticated  opera¬ 
tions  on  or  with  tables.  For  example,  two  tables  can  be  added.  A  simple 
example  is  provided  by  tables  4  and  5. 
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Following  the  object-oriented  programming  style,  we  should  be  able  to 
write 


table  4  +  table  5  =  table  6, 
and  obtain  the  result  in  table  6. 

The  "+"  operator  can  be  overloaded  so  that  it  adds  tables  in  a  specified 
way.  We  obtain  the  total  sales  for  both  regions  by  adding  the  values  in  the 
two  tables.  Note  that  not  all  elements,  but  only  the  appropriate  data 
elements  (those  in  the  sales  column)  are  added.  This  addition  can  be 
repeated  a  number  of  times,  so  that  we  can  get  weekly  results  by  adding  7 
tables  of  daily  data,  or  annual  results  by  adding  12  monthly  data  tables. 

In  a  similar  manner,  we  can  define  subtraction,  scalar  multiplication,  and 
scalar  division  operations  for  tables. 


Header 


Cell  cage 


Cell 


Interpolation 


Notes 


Column 

header 


Rectangular 


Numeric 


Yes 


Row 

header 


Multiples 


String 


No 


Collapsing 

multiples 


Blank 


Footnotes 


Cell  notes 


other  notes 


Both 


Combination 


Graphic 


Composite 


Figure  20.  A  spectrum  of  generable  table  types  in  profile  representation. 


Table  4.  Sales  in  East 

Item 

Sales 

Region. 

($) 

Coffee 

250 

Donuts 

890 

Table  5.  Sales  in  West 

Item 

Sales 

Region. 

($) 

Coffee 

220 

Donuts 

1000 

Table  6.  Result  table: 

Item 

Sales 

sales  in  both  regions. 

($) 

Coffee 

470 

Donuts 

1890 
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9.3  Representation  of  Structure 

What  representation  would  give  software  tables  the  functionality  of  real- 
world  tables?  Object-oriented  programming  techniques  are  the  answer.  A 
table  class  category  can  be  defined,  and  specific  table  objects  can  be 
instances  of  classes  from  that  category.  Since  tables  come  in  a  wide  variety 
and  serve  a  variety  of  functions,  they  call  for  a  number  of  classes,  which 
can  be  derived  from  base  classes. 

The  table  anatomy  given  in  section  9.1.1  is  a  good  starting  point  for 
designing  a  structure  for  the  table.  A  table  is  first  divided  into  several 
components  (table  title,  column  header,  row  header,  table  data  body,  and 
notes).  The  column  header,  row  header,  and  table  data  body  consist  of 
several  cells.  These  components  themselves  can  be  represented  by  compo¬ 
sition  classes  (that  is,  a  collection  of  other  classes/ objects)  containing 
several  cells.  The  cells  in  turn  contain  numbers,  text  strings,  graphic 
symbols,  and  so  forth.  Therefore,  the  cells  will  be  represented  by  several 
distinct  types  of  classes.  In  a  separate  report  (ARL-TR-2041),  I  discuss 
computer  representations  of  tables  in  detail  (Karamchetty,  2000a);  here  I 
give  only  a  brief  description. 

Traditionally,  cells  in  a  table  are  represented  as  elements  of  a  two- 
dimensional  array.  But  such  a  representation  inherently  limits  the  table  to 
a  rectangular  arrangement.  It  cannot  handle  tables  where  columns  have 
subcolumns  and  where  columns  (or  rows)  combine.  We  can  avoid  this 
limitation  by  decoupling  the  table  structure  and  the  data  (see  fig.  21). 

Table  structure  (both  headers  and  data  body)  is  captured  in  a  cell  cage. 

The  cells  are  numbered  by  their  row  and  column  indexes  (0,0;  0,1;  etc).  An 
array  of  all  cell  locations  and  pointers  to  data  is  set  up  as  shown  in  figure 
21.  We  can  define  mathematical  properties  for  the  cell-cage  structure.  That 
is,  the  cell-cage  location  can  be  computed  by  means  of  the  cell-cage  array 
location,  the  cell-cage  type,  and  cell-cage  size.  The  array  location  and  cell- 
cage  location  can  yield  adjacency  lists  that  show  which  cells  have  neigh¬ 
borly  relationships.  The  array  element  also  points  to  the  contents  of  the 
cell.  This  indirect  pointer  notation  connects  the  cell-cage  location  and  the 
contents.  The  separation  of  both  the  structure  and  the  contents  of  a  table 
is  in  harmony  with  the  philosophy  that  operations  on  the  table  should  be 
generic. 

Table  column  headers  (and  row  headers,  where  applicable)  describe  what 
the  column  (row)  represents.  Each  cell  of  a  header  typically  consists  of  a 
variable  (and  often  a  symbol  for  that  variable)  and  a  string  descriptor. 

In  most  science  and  engineering  applications,  symbols  are  used  for 
variables,  which  may  be  explained  on  first  use  or  in  a  list  of  notation  (akin 
to  the  data  dictionary  in  database  systems).  For  example,  in  equations, 
tables,  and  graphs,  one  might  use  p  as  the  variable  standing  for  pressure. 
This  definition  would  be  included  in  the  list  of  notation.  Some  books 
additionally  carry  a  list  of  units,  with  entries  such  as  "p,  psia."  But  it  is 
common  to  indicate  the  units  on  the  list  of  notation,  with  entries  such  as 
"p,  pressure  (psia)."  (Such  an  entry  could  correspond  to  a  column  header 
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Figure  21.  Cell-cage 
array  connects  cell 
locations  and 
contents. 


cell.)  In  a  Natural  Computing  document,  the  list  of  notation  will  bring 
together  all  the  variables  in  the  document  along  with  explanations.  In 
fact,  each  table  header  cell  pointer  should  point  to  a  unique  memory 
location  where  the  variable  and  its  notation  and  explanation  are  stored.  In 
some  cases,  different  variables  are  used  for  the  same  quantity  in  separate 
contexts;  such  situations  can  be  handled  separately. 


9.4  Development,  Choice,  and  Use 

In  the  foregoing,  I  have  identified  a  number  of  different  types  of  tables. 
The  most  frequently  used  tables  can  be  selected,  programmed  by  a  soft¬ 
ware  developer,  and  provided  in  a  tool  box  or  Natural  Computing  envi¬ 
ronment  for  use  by  domain  specialists,  w;ho  will  select  a  table  type  that 
best  fits  the  needs  of  a  particular  application.  Thus,  an  instance  of  a  blank 
table  is  created.  In  the  creating/ editing  mode,  all  data  and  information 
are  entered  into  the  table  by  the  domain  specialist,  who  is  also  responsible 
for  choosing  and  filling  in  the  footnotes  and  other  notes  as  applicable.  The 
table  object  also  develops  a  number  of  behavioral  characteristics  for  the 
domain  specialist  to  review.  For  example,  the  domain  specialist  records 
the  limit  values  (minimum,  maximum,  and  singularities)  of  a  characteris¬ 
tic.  The  table  object  would  use  these  limits  to  flag  an  error  message  if  a 
user  tries  unallowable  values.  This  is  another  table  feature  that  we  want 
to  capture  so  that  our  software  can  imitate  human  usage  of  tables;  in  real- 
world  applications,  domain  specialists  often  provide  such  checks.  Mini¬ 
mum  and  maximum  values  of  a  variable  prevent  extrapolation  outside 
allowable  bounds. 

A  table  object  will  also  have  a  set  of  input  (or  query)  templates  and 
output  templates.  Many  tables  describe  functional  relationships  among 
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quantities  (variables  or  characteristics)  identified  in  the  cells  of  the  col¬ 
umn  header.  Given  one  of  them  (and  appropriate  data),  the  others  can  be 
determined  from  the  table.  We  can  use  this  functional  relationship  in 
generating  query  templates.  The  user  should  be  able  to  choose  the  appro¬ 
priate  input  template,  type  in  a  value  for  the  independent  variable, 
submit  it  to  the  table  object,  and  obtain  the  result  in  an  output  template. 
The  input  template  also  guides  the  user  with  the  limits  on  the  variable 
values.  These  guidance  values  in  the  templates  protect  a  table  from 
invalid  or  out-of-range  queries.  A  table  with  input  and  output  templates 
can  be  likened  to  a  computer  hardware  component  with  its  input  and 
output  sockets  and  pins.  These  input  and  output  templates  are  very 
useful  in  connecting  different  functional  objects  into  a  procedure  (proce¬ 
dures  are  described  in  sect.  12). 

9.5  Search  for  Data 

Since  the  cells  in  a  table  can  be  connected  by  adjacency  lists  and  pointers 
to  neighbors,  and  pointers  lead  to  data  values  or  contents,  searching 
a  table  for  result  data  items  is  very  simple.  A  query  consists  of  an 
independent-variable/value  pair  and  a  dependent  variable.  We  wish  to 
find  the  value  corresponding  to  the  dependent  variable.  We  use  the 
simple  property  of  a  table  that  two  value  cells  bear  the  same  neighborly 
or  adjacency  relationship  as  the  corresponding  two  variable  cells  do.  This 
relationship  is  depicted  in  figure  22. 


Figure  22.  Adjacency 
property  is  used  to 
get  table  values. 
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9.6  Visibility  of  Data 

Educators  criticize  current  software  systems  as  black  boxes:  because  the 
solution  method  is  opaque  to  the  user,  the  user  learns  nothing  from  the 
software.  Even  domain  specialists  do  not  understand  what  is  in  the  code 
once  their  domain  information  is  coded  by  a  software  developer.  With 
traditional  media  (paper,  calculator,  and  pencil),  students  continue  to 
learn  as  they  solve  a  number  of  problems.  With  traditional  computer 
software,  a  student's  learning  has  no  correlation  with  the  number  of 
problems  solved.  In  contrast,  because  tables  in  Natural  Computing  reveal 
themselves  and  show  relationships  between  variables,  a  student  can 
realize  opportunities  available  and  watch  out  for  pitfalls  in  the  problem 
domain  represented  by  each  table. 

9.7  Table  Data  Storage 

In  Natural  Computing,  data  in  table  components  are  stored  in  tagged  or 
named  and  connected  arrays.  A  domain  specialist  would  choose  the  type 
of  table  needed  for  a  specific  application.  Generic  table  structures  and 
methods  would  be  automatically  available  for  the  application.  The  spe¬ 
cialist  would  also  specify  the  size  of  the  table. 

9.8  Display 

As  pointed  out  in  section  8,  current  software  systems  have  addressed  the 
display  of  tables  extensively.  Display  is  an  important  aspect  of  Natural 
Computing,  since  domain  specialists  and  users  interact  with  displayed 
tables.  Again,  display  functions  and  methods  are  developed  for  generic 
tables.  The  end  users  are  given  greater  flexibility  to  choose  the  displays 
that  most  suit  their  needs  and  comfort  level.  Natural  Computing  should 
follow  the  display  practices  that  are  commonly  found  in  books  and 
currently  popular  software,  since  these  represent  the  most  natural  way  for 
users  to  use  and  understand  tables.  However,  three  t5q3es  of  displays  are 
needed:  (1)  for  tables  embedded  in  text,  (2)  for  activated  tables  for  interac¬ 
tive  calculations,  and  (3)  for  tables  40 

to  create  procedures. 

9.9  Testing  a  Table  in  Isolation 

Testing  is  a  key  task  in  software  development.  Capturing  an  application 
domain  in  software  is  equally  critical.  By  isolating  a  table  and  testing  it 
for  a  variety  of  inputs,  together  with  the  built-in  justifications,  limits, 
behaviors,  and  responsibilities  prescribed  for  a  table  class,  a  Natural 
Computing  programmer  can  go  a  long  way  toward  eliminating  bugs  in 
software  that  uses  tables.  Since  the  filters  on  the  table  will  allow  only 
preapproved  types  and  ranges  of  values,  isolated  testing  can  come  very 
near  guaranteeing  the  software  and  the  domain  information. 
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9.10  Growth  of  a  System 

Two  types  of  system  growth  can  be  anticipated.  The  first  is  domain 
growth.  A  given  domain  will  incorporate  more  complex  problems,  and 
other  complex  problems  will  cover  a  wide  variety  of  domains.  As  domain 
coverage  grows,  tables  will  need  to  be  represented  with  more  complex 
features.  As  new  table  features  (either  structure  or  behavior)  are  encoun¬ 
tered  (or  invented),  software  developers  will  play  a  primary  role  in 
developing  those  extended  features.  This  second  kind  of  growth  will 
result  in  new  software  tools  and  environments  or  new  versions  of 
software. 


10.  Graphs 


In  section  9, 1  focused  on  describing  table  objects  to  demonstrate  the 
importance  of  using  natural  objects,  as  well  as  showing  methods  to 
implement  them.  However,  in  addition  to  tables.  Natural  Computing 
consists  of  graphs,  equations,  and  diagrams.  The  philosophy  for  repre¬ 
senting  these  objects  is  similar  to  that  used  for  table  objects.  In  this  sec¬ 
tion,  I  briefly  describe  the  representation  of  graph  objects. 

10.1  State  of  Art  in  Graph  Representation 

The  last  decade  of  computer  development  has  seen  an  explosion  of 
graphics-based  programming.  Currently,  powerful  picture  and  image 
presentation  and  processing  software  systems  are  commercially  available. 
Many  programs  generate  and  output  excellent  graphs,  curves,  or  charts. 
Figure  4  is  an  example  of  an  excellent-looking  and  complex  graph  gener¬ 
ated  by  Mathematica®  for  a  user  to  see  but  to  do  no  other  computation. 

This  class  of  programs  generates  graphs  as  ends  (in  the  words  of  Coad 
and  Yourdon,  1991)  in  themselves.  Currently,  no  programs  exist  that  use 
graphs  as  the  means  for  calculations.  In  paper-based  calculations,  users 
use  graphs  to  observe  trends  and  discern  the  behavior  of  variables.  Most 
notably,  they  use  graphs  to  obtain  resultant  values.  Using  graphs  in 
calculation  helps  people  understand  the  "physics"  of  a  problem.  Take  the 
example  of  the  pipe  friction  coefficient  graph  in  figure  23  (Karassik,  1976). 
With  sophisticated  equation-fitting  programs,  it  is  possible  to  develop  a 
highly  complex  set  of  equations  to  replace  this  graph.  But  in  the  process, 
the  intuition  into  the  problem  is  completely  lost.  A  hydraulics  specialist 
and  an  end  user  will  notice  three  distinct  regions  from  this  graph.  The 
first  one  is  the  laminar  flow  region,  where  the  friction  coefficient  is  a 
function  of  Reynolds'  number  and  is  not  a  function  of  surface  roughness. 
Then  there  is  a  transition  region  where  the  pipe  friction  is  not  well  de¬ 
fined.  The  third  region  is  the  turbulence  region,  where  the  pipe  friction  is 
strongly  influenced  by  surface  roughness.  For  each  pipe  roughness  value, 
the  curves  generally  tend  to  become  flat  after  a  certain  Reynolds'  number 
value.  No  equation  can  represent  the  functional  relationship  depicted  by 
the  graph  in  figure  23  and  be  intuitive  enough  that  a  domain  specialist  or 
user  can  notice  that  he  or  she  is  operating  in  a  distinct  region  of  behavior 
of  the  fluid  (Streeter,  1971).  On  the  other  hand,  the  graph  teaches  or 
reminds  the  user  that  two  distinctly  different  variables  influence  the 
results  in  the  regions.  The  visibility  of  the  underlying  processes  in  com¬ 
puting  is  the  most  important  reason  to  discard  black-box  programming 
and  use  visible  and  intuitive  programming  methods.  Natural  Computing 
graphs  are  essential  to  maintaining  this  visibility  and  intuitive  usefulness. 

Many  of  the  points  made  in  section  9  about  tables  also  apply  to  graphs 
and  other  Natural  Computing  objects.  In  this  section,  I  briefly  describe 
some  of  the  features  specific  to  graphs. 

‘‘Such  as  Theorist  and  TableCurve  (described  in  Douglas  A.  Smith  and  James  P.  Adams,  Scientific  Comput¬ 
ing  and  Automation,  July  1993, 27-28). 
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VALUES  OF  (VD')  FOR  WATER  AT  60"F (VELOCITY  IN  FT/SEC  =  DIAMETER  IN  INCHES) 
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Fig.  28  Moo(iy  diagram.  (V.  L.  Streeter,  “Fluid  Mechanics,”  6th  ed.  Copyright  1971  by  McGraw-Hill  Book 
Company,  New  York) 


Source:  Igor  J.  Karassik,  William  C.  Krutzsch,  Warren  H.  Fraser,  and  Joseph  P.  Messina,  eds.  (1976). 
Pump  Handbook,  McGraw-Hill  Book  Co.,  New  York,  NY. 


Figure  23.  Example  graph  showing  how  a  graphical  relationship  provides  visibility  to  data  and 
information. 


10.2  Natural  Computing  Graph  Representation 

One  represents  a  graph  object  by  (declaring,  (defining,  and  implementing  a 
graph  class.  For  computer  internal  storage  purposes,  graphs  can  be 
represented  either  by  a  table  of  x  and  y  coordinates  or  by  an  equation.  In 
the  former  case,  a  graph  class  will  have  a  two-dimensional  array  of  data 
members  containing  the  x  and  y  coordinates.  The  number  of  sets  of  points 
depends  on  the  complexity  of  the  graph  and  the  desired  accuracy.  If  there 
is  more  than  one  line  or  curve  in  the  graph,  a  multidimensional  array  can 
be  used  and  a  parameter  value  is  associated  with  each  line  or  curve. 
Consequently,  a  graph  class,  in  turn,  will  use  an  equation  object  as  a 
member  or  a  table  object  as  a  member  to  represent  the  data  for  the  graph. 

Graphs  also  have  captions.  The  captions  are  listed  in  a  table  of  contents  to 
indicate  all  graphs  available  in  a  document.  The  other  salient  members  of 
a  graph  class  are  the  x  and  y  axes,  labels  for  x  and  y  axes,  and  other  notes. 
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Like  tables,  some  graphs  can  be  interpolated  along  a  curve,  among  a  set 
of  curves,  or  both,  while  some  other  graphs  cannot  be  interpolated.  This 
interpolation  characteristic  is  an  attribute  of  a  graph  class.  The  informa¬ 
tion  needed  to  display  a  graph  (picture  size,  grid  lines,  line  styles,  and  so 
forth)  is  captured  as  part  of  the  display  data  members  of  a  graph.  It  is 
interesting  to  note  two  points:  (1)  the  display-related  information  is  not 
needed  for  calculations  of  results  using  graphs,  and  (2)  calculations  are 
essentially  done  as  if  the  data  were  in  a  table  or  an  equation.  Graphs 
should  carry  a  cursor  whose  shape  can  be  changed  at  the  user's  discre¬ 
tion.  A  full-size  crosshair  could  be  moved  along  the  graph  that  highlights 
the  point  on  the  graph  that  is  being  examined.  In  place  of,  or  besides  a 
cursor,  a  property  window  could  be  displayed,  indicating  numerical 
values  at  the  point  of  examination.  As  a  user  scans  a  graph,  the  cursor  or 
crosshairs  should  move  over  the  graph,  and  the  property  window  dis¬ 
plays  the  numerical  values  of  the  variables  at  the  point  on  the  graph. 

On  hard  copies,  the  accuracy  obtainable  from  graphs  is  limited  by  the 
paper  size.  On  the  computer,  zooming  in  allows  the  accuracy  of  graphs  to 
be  improved,  if  detailed  data  are  available.  However,  the  use  of  a  prop¬ 
erty  window  can  give  us  highly  accurate  results  up  to  several  significant 
digits,  perhaps  making  zooming  unnecessary.  (Excessive  zooming  could 
actually  lead  to  a  temporary  loss  of  the  visibility  of  the  overall  trend  of 
results.) 

Graphs  would  carry  input  and  output  boxes  so  that  the  user  can  type  in 
input  values  and  see  the  results  from  the  graph  in  the  output  box.  Both 
types  of  boxes  would  carry  names  of  the  variables  and  their  units.  Graphs 
too  would  have  filters  and  justifiers  to  check  the  consistency  of  data  and 
units.  Graphs  would  also  have  lower  and  upper  bounds,  as  well  as 
singularities  in  between.  With  these  facilities,  graphs  could  be  seen, 
interactively  used,  and  connected  into  procedures.  In  many  ways,  graph 
objects  will  have  characteristic  behaviors  similar  to  those  of  tables  (graphs 
are  the  subject  of  a  separate  report  (Karamchetty,  2000b)). 

The  example  of  steam  tables  is  again  applicable.  Historically,  steam 
engineers  used  the  Mollier  chart,  which  represented  the  properties  of 
steam  graphically.  One  could  quickly  perform  or  do  steam  power  plant 
calculations  by  laying  out  the  thermal  processes  on  the  Mollier  chart.  One 
could  visually  represent  the  complete  steam  cycle  by  marking  the  various 
state  points  on  the  chart. 

The  old  paper  Mollier  charts  suffered  from  inaccuracies.  Replacing  them 
with  Natural  Computing  graphs  in  electronic  media  and  using  property 
windows  could  improve  accuracy  while  retaining  their  visual  benefits. 
Steam  cycles  could  be  laid  out  on  these  charts  with  great  speed.  A  Mollier 
chart  represents  the  properties  of  liquid  water,  water  and  steam  mixture, 
and  superheated  steam.  Various  temperature,  pressure,  steam  quality 
(dryness),  and  specific  volume  contours  are  drawn  on  the  chart.  A  line  is 
also  shown  that  presents  the  states  that  separate  the  liquid  and  mixture 
states  on  the  one  side  and  the  vapor  and  mixture  states  on  the  other.  The 
contours  are  completely  interpolatable  for  all  properties. 
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Steam  engineers  find  the  chart  highly  useful  in  ensuring  that  various 
dryness  qualities  are  adhered  to  in  designing  equipment.  Although 
computer  programs  are  now  available  to  calculate  steam  cycles,  none  of 
them  can  match  the  visibility  and  simplicity  of  a  Mollier  chart.  With 
Natural  Computing,  one  can  restore  the  visibility  while  maintaining  the 
accuracy  and  speed  of  the  computing  methods.  Additionally,  one  can  lay 
problems  out  on  the  chart  on  the  fly,  while  preserving  the  speed,  accuracy, 
and  efficiency  of  computer  calculations. 


11.  Equations 


Equations  are  the  last  of  the  three  functional  representations.  I  do  not 
propose  to  describe  this  feature  in  any  great  detail,  as  a  number  of  current 
software  systems  allow  equations  to  be  typed  in  and  used  as  functional 
relationships.  But  the  use  of  equations  along  with  graphs  and  tables  in 
Natural  Computing  is  very  powerful.  Moreover,  the  representation  and 
use  of  equations  follow  the  philosophy  and  methods  described  in  the 
foregoing  sections. 

Equations  are  developed  as  a  category  of  classes.  An  equation  class 
consists  of  member  data  representing  the  operators  and  operands  in  a 
given  sequence.  Their  relationship  is  captured  in  the  form  of  a  tree 
structure. 

A  noteworthy  feature  of  equation  classes  in  Natural  Computing  is  that 
they  have  a  justifier  function  that  protects  an  equation  object  from  mixing 
quantities  of  dissimilar  units.  For  example,  the  units  justifier  evaluates  the 
units  of  each  expression  and  flags  inconsistencies  in  the  units.  For  ex¬ 
ample,  the  units  of  all  operands  of  the  operators  =,  +,  and  -  should  be  the 
same. 

Like  tables  and  graphs,  equation  classes  also  carry  input  and  output 
boxes  so  that  the  user  can  t5q)e  in  input  values  and  see  the  results  from 
the  graph  in  the  output  box.  Both  types  of  boxes  carry  the  names  of  the 
variables  and  their  units.  Equations  are  identified  by  an  equation  number 
and  caption.  These  equation  numbers  and  captions  can  be  grouped  into  a 
list  of  equation  captions  for  indexing.  (Although  the  use  of  equation 
captions  is  not  common  in  printed  media,  they  would  clearly  be  useful 
for  portable  electronic  documents.)  Figure  24  shows  an  example  of  an 
equation  with  input  and  output  templates  for  inserting  inputs  and  obtain¬ 
ing  result  values. 


Figure  24.  An 
example  showing 
interactive  use  of  an 
equation. 
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12.  Procedures 

In  paper-based  calculations,  people  develop  procedures  by  combining 
several  objects  (tables,  graphs,  and  equations).  The  output  of  one  object  is 
used  as  input  to  another  object,  and  so  on  in  some  sequence.  People  use 
each  of  the  objects,  note  intermediate  results  on  a  scratch  pad,  carry  them 
into  the  next  object,  and  so  on. 

In  a  predefined  procedure,  this  chaining  is  done  at  the  variable  level.  To 
facilitate  this  process,  in  Natural  Computing,  I  define  a  new  object  called 
a  pipe.  In  its  simplest  form,  a  pipe  has  a  donor  and  a  donee  (a  recipient).  A 
donor  is  a  variable  that  provides  its  value  to  the  pipe.  The  pipe  carries 
that  value  to  the  donee,  which  is  a  variable  in  another  (downstream) 
object.  In  more  complex  pipes,  a  pipe  can  have  several  pairs  of  donors 
and  donees. 

One  can  set  up  procedures  by  chaining  several  equations,  tables,  graphs, 
and  other  procedures  to  compute  a  complex  calculation  repeatedly.  In 
that  sense,  a  procedure  is  like  a  computer  program.  But  a  procedure  still 
retains  a  high  level  of  visibility,  since  the  user  can  open  up  a  procedure 
and  inspect  its  component  objects. 

A  large  procedure  can  be  built  from  a  number  of  small  procedures.  By 
testing  and  verifying  each  procedure  in  isolation,  one  can  assure  high 
quality  for  the  composite  procedure.  A  domain  specialist  can  reuse  and 
rearrange  the  components  of  a  procedure  and  develop  a  new  procedure. 
Figure  25  shows  a  procedure  that  consists  of  several  graphs  and  tables 
connected.  This  procedure  can  be  inserted  into  a  program  as  step  k.  When 
a  procedure  is  opened  up,  the  details  of  it  become  visible. 


Figure  25.  A  Natural 
Computing  procedure 
example. 
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13.  Pictures 


Paper-based  computing  uses  sketches,  drawings,  and  schematics  to  show 
the  relative  positions  of  variables  and  properties.  For  example,  a  sketch  or 
a  drawing  may  show  a  number  of  dimensions  of  a  component  or  an 
assembly.  Some  of  the  dimensions  are  used  in  equations,  tables,  and 
graphs.  One  can  set  up  a  procedure  in  which  the  dimension  placed  on  a 
sketch  or  a  drawing  can  be  piped  into  a  procedure  and  made  part  of  that 
procedure.  Or  in  reverse,  a  calculation  can  generate  a  size,  which  can  be 
piped  into  a  drawing.  Figure  26  shows  a  sketch  from  which  values  of 
variables  can  be  connected  to  an  equation. 

Schematic  diagrams  are  extensively  used  in  engineering.  A  schematic 
diagram  shows  how  various  components  are  connected  and  how  a 
flowing  fluid,  for  example,  changes  its  state.  Figure  11  showed  a  sche¬ 
matic  diagram  of  a  thermal  power  plant.  Water  or  steam  flows  through 
pipes  and  components,  and  during  the  course  of  its  flow,  steam  changes 
its  state.  There  are  equations,  tables,  and/or  graphs  that  relate  various 
properties  of  these  states.  Schematics  add  another  dimension  to  the 
visibility  and  understanding  of  a  problem. 


Figure  26. 
Dimensions  from 

(a)  a  sketch  used  in 

(b)  an  equation. 
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14.  Text 


Natural  Computing  calculation  features  are  embedded  in  text  as  in  a 
document  or  book.  Text  along  with  tables,  graphs,  and  equations  is 
displayed  for  a  reader  to  peruse.  Two  other  modes  are  available:  use 
within  a  document,  or  reuse  in  other  documents.  Any  time  the  end  user 
wishes  to  do  a  simple  calculation  using  any  of  these  objects  embedded  in 
text,  that  object  can  be  activated.  Appropriate  inputs  into  the  objects  will 
produce  resultant  values.  After  using  those  objects,  the  end  user  can 
revert  to  reading  the  text  by  closing  those  objects.  This  is  the  within- 
document  mode.  In  the  reuse  mode,  an  end  user  can  develop  new  proce¬ 
dures  by  copying  objects  from  documents  and  connecting  them.  These 
procedures  can  be  saved  for  future  use.  Figure  27  shows  a  procedure 
embedded  in  text. 
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portion  replaced  by  the  internal  forces.  Then,  the  cut 
portion  would  exert  a  direct  shear  force  Fand  a 
torsion  Ton  the  remaining  part  cf 
superposition,  the  maximum  str^ 
computed  using  the  equation 


Tmax  : 
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Replacing  the  terms  by 

r=FD/2, 

r=d/2, 

J=7td'^/32,and 
A  =  Jtd^/ A 
gives 

..  8FD  ,  4F 


nd^ 


In  this  equation,  the  subscript  inc 
shear  stress  has  been  omitted  a 
unnecessary.  The  positive  signs 
retained,  and  hence  Eq.  (b)  give 
the  inside  fiber  of  the  spring. 

Now  define  spring  index 

C  =  £ 
d 

as  a  measure  of  the  coil  curvatui; 
Eq.  (b)  can  be  arranged  to  give 


I  Procedure 


Figure  27.  Natural  computing  text  with  procedure. 
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15.  Conclusions 


Traditional  programming  or  software  development  focused  on  making  it 
easy  for  a  software  developer  while  he  or  she  tried  to  understand  a 
domain  and  worked  in  it.  Database  systems  aimed  at  achieving  math¬ 
ematical  correctness  and  elegance  (Date,  1995)  versus  emulating  real- 
world  tables.  Software  systems,  such  as  word  processors  and  computer- 
aided  drafting  systems,  have  broken  that  tradition  and  provided  domain 
users  with  generic  software  for  use  with  no  further  assistance  from 
software  developers. 

Scientists  and  engineers  use  information  from  reference  books,  textbooks, 
and  journals.  Reference  information  is  useful  over  long  time  periods, 
while  textbook  information  is  more  recent.  Journal  information  relates  to 
the  latest  inventions  or  discoveries.  With  Natural  Computing  documents, 
after  reading  about  an  interesting  new  scientific  discovery  in  a  journal,  a 
scientist  can  readily  combine  it  with  existing  information  in  textbooks  or 
reference  books,  since  this  process  of  combining  information  is  extremely 
simple.  The  scientist  can  copy  the  Natural  Computing  feature  (equation, 
graph,  table,  procedure,  or  picture)  and  combine  it  with  an  existing 
procedure.  Presto!  A  new  algorithm  or  procedure  is  instantly  developed 
for  further  use.  The  scientist  can  instantaneously  communicate  it  to  others 
interested  in  the  new  procedure.  This  is  what  I  mean  by  asserting  that 
Natural  Computing  allows  for  the  creation  and  communication  of  new 
knowledge. 

Natural  Computing  focuses  on  developing  generic  calculation  software 
for  use  by  domain  specialists  in  science,  engineering,  and  other  fields  that 
depend  on  calculation.  With  the  Natural  Computing  environment  and 
tools,  domain  specialists  could  work  with  tables,  graphs,  equations, 
procedures,  pictures,  and  text.  Among  the  benefits  of  this  approach  are 
economical  and  affordable  generation  of  applications,  high  quality  of 
software  and  applications,  high  growth  potential  for  applications,  high 
reuse  of  applications,  ready  availability  of  high-utility  information  in 
electronic  media,  and  rapid  transmission  of  domain  information. 
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